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^  Military  contracts  for  the  development  and  pro¬ 
curement  of  weapon  systems  and  associated  hardware  com¬ 
ponents  deal  with  definitional  statements  concerning 
those  products  called  technical  requirements .  Concep¬ 
tually,  there  are  different  types  of  technical  require¬ 
ments  which  range  from  broad  goals  stated  in  Mission 
Requirements,  to  subtle  and  small  details  reflected  in 
Design  Requirements. 

This  dissertation  was  a  pilot  study  on  technical 
requirements  and  was  split  into  two  parts.  The  first 
part  investigated  documents  which  commonly  reflect  re¬ 
quirements  in  Air  Force  developments.  The  document 
type  chosen  was  the  Part  One  Critical  Item  Specification. 
The  intent  of  this  part  of  the  research  was  to  see  if 
proposed  conceptual  requirement  types  could  be  found  in 
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standard  documents,  and  if  so,  whether  the  types  fully 
exhausted  the  document's  supply  of  requirements.  Study 
results  indicated  that  the  proposed  categories  were 
appropriate  but  that  the  overlap  between  requirement 
types  made  isolation  a  gross  rather  than  precise  pro¬ 
cess.  Recommendations  for  future  study  of  this  area 
included  proposal  for  a  small  group  investigation  of 
requirement  counting  and  classifying. 

The  second  part  of  the  study  was  to  investigate 
the  relationship  between  the  requirement  categories. 

A  common  belief  in  military  development  circles  is  ^fhat 
there  is  an  orderly  growth  evidenced  in  requirement 
types  through  a  project's  development  life  cycle.  All 
requirement  types  are  known  to  grow  with  time.  Depend¬ 
ing  on  the  requirement  type,  it  is  believed  that  some 
grow  faster  than  others  and  that  this  growth  is  pre¬ 
dictable.  Data  were  analyzed  and  a  growth  model  consis¬ 
tent  with  the  results  was  proposed.  Recommendations 
for  future  study  included  the  specific  areas  to  be 
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CHAPTER  013  -  HISTORICAL  BACKT-RCU.'.T/ 

Introduction 

Since  man  first  shaped  a  stone  into  a  wheel,  he 
has  pursued  an  increasingly  complex  process  of  sorting 
and  analyzing  his  steps  and  their  consequences .  Iron¬ 
ically,  perhaps,  the  process  has  received  the  nest 
sophisticated  attention  in  one  of  the  areas  that  most 
affects  man's  short-run  survival  -  -  the  development 
of  weapons.  This  dissertation  deals  with  complex 
weapons  and  associated  equipment  as  they  are  developed 
by  the  United  States  Air  Force  in  conjunction  with  Amer¬ 
ican  aerospace  companies. 

The  specific  focus  is  on  requirements ,  a  term 
much  used  in  weapon  system  acquisition,  but  one  which 
is  quite  ambiguously  defined.  A  key  objective  is  to 
more  rigorously  study  the  term  "requirement"  to  identify 
a  taxonomy  of  requirement  types  present  in  the  weapon 
acquisition  process.  Each  requirement  type  is  evaluated 
for  its  potential  to  be  isolated  and  counted  using  stan¬ 
dard  documents  of  the  development  process.  Finally, 
relationships  between  the  initial  numbers  of  require¬ 
ments  in  each  category  and  those  numbers  at  some  common 
conceptual  point  later  in  the  development  cycle  are  in¬ 
vestigated  . 

1 
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Definition  of  a  Requirement 

A  requirement  is  "something  wanted  or  needed"  as 
defined  by  Webster.  The  weapons  acquisition  process  has 
evolved  more  constraints  on  this  basic  definition.  Al¬ 
though  this  modified  definition  is  net  legitimized  by  th 
Air  Force  in  a  formal  glossary,  it  is  commonly  accepted 
in  practise: 

A  requirement  is  a  formally  expressed  goal  whose 

outcome  can  be  individually  verified. 

This  simple  definition  carries  some  background  elements 
with  it  generated  by  the  unique  environment.  First,  a 
requirement  is  understood  to  be  a  formal  expression. 

This  means  it  must  be  written  or  recorded  so  as  to  be 
available  for  verification  of  its  various  terms.  It 
also  means  that  it  must  be  transmitted  from  one  party  to 
another  in  a  commonly  accepted  format.  A  specification 
document  is  a  common  American  convention  for  trans¬ 
mitting  requirements.  The  outcome  of  a  requirement 
must  be  independently  verified  upon  completion.  This 
can  be  in  the  form  of  a  test,  an  analysis,  or  an  in¬ 
spection.  Exhibit  One  gives  a  typical  specification 


format. 


AN/ARN-10C0  SPECIFICATIONS 


1.  The  AR/ARN-1000  Airborne  Radio  shall  operate  in  the 
low  frequency  band  and  will  provide  accurate  long 
range  navigation  for  B-52,  FE-111  and  KC-135  air¬ 
craft. 

2.  The  radic  shall  consist  of  the  following  components 
receiver  unit,  processor  unit,  control  and  display 
equipment,  antenna  coupler  unit,  and  equipment  rack 

3.  The  receiver  unit  shall  take  signals  from  the  anten 
na  coupler  unit  and  smooth.  The  resultant  signal 
shall  be  sent  to  the  processor  unit. 

3.1  The  receiver  unit  shall  conform,  to  MI1-SFEC  XXXX 
provisions  for  reliability'  and  shall  include  the 
following  components. 

3.1.1  Component  A  consists  of  . . 

3.1.2  Component  B  consists  of  . 

3.1.3  Component  C  consists  of  . 

3. 1.3-1  Component  C/l  consists  of  . 

3. 1.3*2  Component  C/2  consists  of  . 

3.2  The  processor  unit  shall  consist  of  ..... 

A.  Total  system  mean-time-to-repair  shall  not  exceed 
150  hours. 


EXHIBIT  ONE 

CAPSULIZED  EXAMPLE  OF  A  SPECIFICATION  DOCUMENT  PAGE 
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Study  Context 

A  weapon  system  moves  from  vague  concept  to  con¬ 
crete  reality  in  halting  and  non-uniform  steps.  Even 
knowledge  of  the  broadest  weapon  system  needs  is  often 
imperfect  and  subject  to  change  over  time,  because  of 
perceived  threat  modification,  technological  break¬ 
throughs,  and  changing  priorities  for  scarce  resources. 
This  leads  to  an  imperfect  and  shifting  base  of  require¬ 
ments  upon  which  still  more  tenuous  alternatives  and 
trade-offs  are  made.  The  level  where  many  operational 
needs  begin  to  coalesce  around  one  weapon  system  which 
will  satisfy  all  these  needs  is  the  highest  rung  in  a 
requirements  ladder  (See  Exhibit  Two) .  The  amalgama¬ 
tion  of  needs  derived  from  specific  Air  Force  documents, 
such  as  Required  Operational  Capability  or  Specific  Op¬ 
erational  Need  papers,  are  coordinated  through  Depart¬ 
ment  of  Defense,  Office  of  Management  and  Budget,  Exec¬ 
utive  Review,  and  Congressional  committee  review  for  ap¬ 
proval.  If  successful,  they  become  a  Program  Management 
Directive,  which  is  levied  from  Headquarters,  Air  Force 
upon  Air  Force  Systems  Command.  Air  Force  Systems  Com¬ 
mand  assigns  the  embryonic  requirements  package  to  an 
intermediate  development  group  (in  the  case  of  aircraft 
and  associated  equipment,  it  is  the  Aeronautical  Sys¬ 
tems  Division) .  This  group  assigns  the  requirement 
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package  and  direct  developmental  responsibility  to  a  Sys 
tern  Program  Office  which  negotiates  with  an  aerospace 
contractor  for  the  actual  engineering  effort.  The  char¬ 
acteristic  of  uncertainty  is  present  in  virtually  all 
development  projects,  regardless  of  its  context.  Peck 
and  Shearer^-  view  weapon  system  acquisition  uncertain¬ 
ties  as  more  intense  and  markedly  different  from  those 
encountered  in  private  business.  The  highest  rung  of 
weapon  system  requirement  ladders  experiences  external 
uncertainties  which  include  postulated  scenarios  of  en¬ 
emy  intentions,  estimated  capabilities  of  competing 
weapons,  and  the  risk  that  national  priorities  will  di¬ 
vert  necessary  funds  away  regardless  of  program  merit. 
Internal  uncertainties  enter  on  lower  rungs.  Since  wea¬ 
pon  systems  usually  push  the  technology  frontier,  the 
uncertainty  is  large.  These  internal  uncertainties  are 
primarily  those  associated  with  encountering  those  new 
technical  difficulties  and  with  the  growing  complexity 
of  a  large  number  of  unknowns,  which  must  interface. 

The  process  of  solving  these  problems  has  become  an  it¬ 
erative  one  : 

The  principle  activities  in  the  major  system  ac¬ 
quisition  process  are  iterative.  As  more  knowl  ige 
of  needs,  alternative  solutions,  actual  capabilities 
resources  and  priorities  is  acquired,  some  steps  in 
the  overall  major  system  cycle  may  be  iterated,  as 
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necessary  to  permit  decisions  to  be  made  in  a 
total  system  context.  It  is  difficult  to  graph¬ 
ically  illustrate  all  of  the  possible  iterations 
which  might  be  involved, ^ 

Uncontrolled  iteration  is  the  bane  of  an  orderly  weapon 
development  process.  Not  surprisingly,  this  has  pushed 
Air  Force  management  to  center  their  attention  on  contrc 
of  the  process.  This  process  perspective,  some  know¬ 
ledgeable  critics  say,  has  come  at  the  expense  of  ade¬ 
quate  attention  to  the  objectives  (requirements)  which 
that  process  was  supposed  to  secure: 

Management  has  the  function  to  solve  problems  that 
stand  in  the  way  of  objectives.  It  is  easy  to  be¬ 
come  so  preoccupied  with  how  we  are  managing  our 
management  systems  that  we  forget  what  we  are  man¬ 
aging  and  why  -  -  our  objectives. 3 

The  Link  to  Public  Administration 

A  systems  management  perspective  and  the  resul¬ 
tant  preoccupation  with  process  to  the  detriment  of 
goals,  is  not  unique  to  the  Air  Force.  This  phenomenon 
has  been  observed  in  the  larger  set  of  American  public 
administration.  One  noted  writer  (Kaufman,  1956) ^ 
traces  the  growth  of  American  public  administration 
through  three  ages.  The  first  age  was  dominated  by 
American  "Yankee  Independence”  which  was  gained,  in 
part,  as  a  reaction  to  harsh  British  rule.  During  this 
age  of  government,  the  individual  rights  of  each  per- 
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son  were  jealously  guarded  and  the  governmental  in¬ 
stitutions  were  established  to  be  as  representative  of 
constituents  as  possible.  Inherent  in  this  system  was 
the  belief  that  popular  goals  could  be  achieved  by 
wresting  some  consensus  from  diverse  inputs.  The  very 
diversity  of  input  allowed  all  important  alternatives 
to  be  considered.  The  democratic  process  of  logical 
debate,  compromise,  and  majority  rule  was  considered  a 
sufficient  mechanism  for  selecting  one  course  from  many. 

As  Kaufman  explains,  this  noble  experiment  even¬ 
tually  developed  a  tragic  flaw.  The  growing  number  of 
decisions  required  of  government,  coupled  with  their  in¬ 
creasing  complexity  and  difficulty,  generated  strong 
pressures  to  reduce  the  diverse  inputs  to  a  manageable 
sub-set.  This  license  to  limit  inputs  was  not  admin¬ 
istered  in  a  manner  to  either  recognize  obligations  to 
diverse  constituencies  or  to  increase  the  probability 
of  netting  all  important  alternatives.  Rather,  it  grew 
as  an  adjunct  of  power  and  the  political  process.  Ac¬ 
cess  to  the  governmental  decision  process  was  increas¬ 
ingly  left  to  the  bureaucratic  specialists  and  their 
immediate  circle  of  constituents.  These  specialists 
were  increasingly  appointed  as  a  result  of  political 


affiliation  and  favor,  rather  than  special  knowledge 
or  sensitivities  to  popular  needs.  In  short,  the  rep¬ 
resentative  style  of  government  eventually  decayed  into 
what  has  commonly  become  known  as  the  "spoils  system", 
present  during  the  time  of  Andrew  Jackson.  The  reaction 
to  this  spoils  system  was  widespread  and  long-standing. 

From  the  1830's  to  the  Pendleton  Act  of  1883, 
criticism  grew  but  no  vehicle  of  change  emerged  (Mosher, 
1968)5.  Even  the  Pendleton  Act,  inspired  by  the  Brit¬ 
ish  civil  service,  was  more  important  for  the  seeds  of 
change  it  carried  than  for  its  revolutionary  impact  on 
the  existing  government.  The  new  civil  service  system, 
wrought  by  the  Pendleton  Act,  accepted  the  dual  prin¬ 
ciples  of  standards  for  minimal  job  competence  and  po¬ 
litical  neutrality  for  its  members.  This  age  is  de¬ 
scribed  by  Kaufman  as  the  "neutral  competency"  age. 

A  hallmark  of  this  politically  neutral  system 
was  job  protection  or  tenure  for  employees  in  virtually 
all  cases  except  gross  impropriety  or  widespread  gov¬ 
ernmental  reduction  in  job  positions  (not  just  people). 
Even  these  cases  were  handled  by  highly  specific,  stan¬ 
dardized  steps,  and  there  was  an  easily  accessable 
appeal  channel  for  job  holders  thus  threatened.  Mem¬ 
bers  of  the  growing  American  bureaucracy  were  thus 
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increasingly  isolated  from  pressures  not  directly  re¬ 
lated  to  actions  of  gross  impropriety.  Further,  the 
standard  for  judging  one's  job  performance  became  ef¬ 
ficiency  -  -  the  accomplishment  of  a  given  task  with  a 
minimum  of  resources  and  energy  expended.  As  the  stan¬ 
dard  of  minimum  performance  became  more  codified  for 
each  job,  the  main  question  became  how  efficiently  one 
met  that  standard.  Both  factors,  the  isolation  inher¬ 
ent  in  political  neutrality,  and  the  growing  emphasis 
on  efficiency  standards  based  on  narrow  job  descriptions, 
caused  an  inward  and  rigid  perspective  on  pre-set  per¬ 
formance  criteria.  Responsiveness  to  change  or  question¬ 
ing  of  job  standards  relative  to  program  goals  gradually 
became  uncommon.  In  General  Holzapple's  modern  day  an- 
ology,  focus  on  the  management  system  has  taken  preci- 
dence  over  concern  for  the  objective. 

Kaufman  sees  the  growing  pressures  on  presi¬ 
dents  such  as  Kennedy,  Johnson,  and  Nixon  to  cut  through 
bureaucratic  red  tape  as  indicative  of  the  third  age  -  - 
that  of  "executive  leadership”.  While  this  age  brought 
a  new  conflict  to  the  members  of  the  burgeoning  Amer¬ 
ican  bureaucracy  from  above,  it  did  little  to  change 
their  narrow  and  rigid  perspective.  This  third  age  has 
meant  confrontation  but  not  obsolescence  of  the  modus 
operandi  established  in  the  second  age. 
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Having  witnessed  the  growth  of  American  public 
administration  in  much  the  same  perspective  as  Kaufman, 
several  public  administration  scholars  stepped  back  from 
the  problem  and  defined  it  in  more  general  terms.  Lloyd 
Nigro  describes  a  characteristic  of  public  administrators 
by  borrowing  a  term  from  Karl  Manheim  called  "functional 
rationality"  : 


A  series  of  actions  organized  in  such  a  way  that  it 
leads  to  a  previously  defined  goal.  Every  element 
in  this  series  of  actions  receiving  a  functional  po¬ 
sition  or  role.  Functional  rationality  is  enhanced 
when  means  are  coordinated  most  efficiently. 


In  Nigro 's  terms,  the1  neutral  competency  period  and  the 
subsequent  executive  leadership  period  had  so  constrained 
administrators'  perspective  inwardly  and  on  process  to 
the  exclusion  of  goals  that  their  actions  could  be  es¬ 
sentially  described  as  functionally  rational.  The  ul¬ 
timate  harm  was  the  de-emphasis  on  objective.  Herbert 
Simon  addresses  more  directly  the  process  an  adminis¬ 
trator  uses  in  decision  making.  He  argues  that  any 
decision  has  in  it  inherent  parts  of  fact  and  values 

Factual  propositions  are  statements  about  the 
observable  world  and  the  way  in  which  it  operates. 

In  principle,  factual  propositions  may  be  tested  to 
determine  whether  they  are  true  or  false  ....  De¬ 
cisions,  are  something  more  than  factual  propo¬ 
sitions....  they  select  one  future  state  of  affairs 
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m  preference  to  another  and  direct  behavior  toward 
the. chosen  alternative.  In  short,  they  have  an 
ethical  as  well  as  a  factual  content. . . .Since  de¬ 
cisions  involve  valuation  of  this  kind,  they  too 
cannot  be  objectively  described  as  correct  or  in¬ 
correct.? 


This  "value’’  (which  is  generally  overlooked)  is  a  mea¬ 
sure  of  the  association  of  the  utility  of  any  given  de¬ 
cision  to  broader  goals.  Often,  it  is  a  testing  of  a 
decision  against  criteria  defined  by  higher  program 
goals.  "Pact"  is  associated  with  the  analysis  of  a 
situation.  It  is  the  latest  analysis  of  "what  is"  in 
a  dynamic  process  of  change.  Analysis  and  emphasis  on 
the  process  of  change  is  a  good  thing  in  that  it  leads 
one  to  seek  logical  relationships  and  to  try  and  find 
patterns  in  a  morass  of  events  and  activities.  The 
quintessence  of  logical  inquiry  was  considered  to  be 
functional  rationalism.  Using  either  Simon’s  or  Nigro ' s 
perspective,  we  see  how  public  administrators  have  evol¬ 
ved  a  systematic  management  approach  preoccupied  with 
logical  sequences  of  activity  and  only  loosely  checked 
by  comparison  with  broader  program  goals. 

It  has  been  argued  that  American  public  admin- 
istratirn  has  evolved  from  a  representative  system  sen¬ 
sitive  to  popular  goals  into  a  bureaucratic  system 
preoccupied  with  management  systems  and  efficiency  stan¬ 
dards.  The  inner  workings  of  a  public  agency  reflect 
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this  general  condition  in  specific  ways.  Emphasis  on 
standards  for  performance  in  an  agency  as  the  test 
rather  than  political  attributes  of  a  job  candidate,  led 
to  detailed  job  descriptions  for  each  position.  Since 
a  person's  job  is  minutely  defined,  performance  is  usual¬ 
ly  measured  by  how  efficiently  he  does  the  prescribed 
job.  No  mention  is  made  in  the  position  description  cf 
license  to  ignore  or  modify  tasks  because  they  may  no 
longer  fit  the  program  goal.  Innovation  is  rarely  re¬ 
warded  if  it  comes  at  the  clear  expense  of  a  written 
task,  because  rewarding  even  a  good  innovation  thusly 
sets  a  precidence  of  condoning  rule  breaking.  Not  only 
does  the  internal  standard  of  each  job  description  fos¬ 
ter  this  narrow  perspective,  but  so  does  the  relationship 
between  job  standards.  As  civil  service  organizations 
have  developed,  a  hierarchy  of  job  position  descriptions 
has  emerged.  Each  job  description  is  formally  related 
to  those  upper,  lower,  and  lateral  positions  by  lines  of 
command  and  coordination.  In  a  real  sense,  the  role  de¬ 
scriptions  of  each  organization  is  thus  functionally 
rationalized . 


1 


The  Air  Force  as  a  Public  Agency 

The  history  of  Air  Force  weapon  system  acquisi¬ 
tion  shows  marked  traits  of  political  buffering  and 
functional  rationality.  From  its  earliest  days,  the 
military  has  used  civilians  directly  controlled  by  the 
civil  service  system  for  a  major  part  of  the  standing 
force  responsible  for  weapon  acquisition.  This  is  the 
same  civil  service  system  spawned  by  the  Pendleton  Acm 
and  just  described  as  now  containing  highly  structured 
job  and  organization  functional  descriptions.  Positions 
not  held  by  civilians  have  been  held  by  military  of¬ 
ficers.  This  officer  corps  grew  during  the  same  time 
as  the  civil  service  system  and  shows  some  common  charac¬ 
teristics.  Although  the  concept  of  an  elite  officer 
corps  is  ancient,  the  constitutional  requirements  for 
civilian  political  appointees  as  leaders  serves  to  blunt 
political  inputs  of  such  a  tight-knit  and  stable  organ¬ 
ization.  This  protection  of  national  decision  making 
channels  from  military  influence  has  had  the  reverse 
'  effect  as  well  -  -  that  of  making  the  military  hierarchy 

resistant  to  diverse  political  influences.  Thus  the 
i  military  also  has  evolved  an  analogous  system  based  on 

job  descriptions  and  functional  rationalism.  While 
there  are  some  major  differences,  such  as  military  job 
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rotation  based  on  individual  career  progression  concerns 
and  not  job  slot  competition,  the  way  civilians  and  mil¬ 
itary  reach  technical  decisions  are  essentially  the  same. 

Air  Force  Acquisition  History 

During  the  days  of  George  Washington,  a  cannon 
was  bought  by  specifying  some  minimal  ar.d  very  gross 
functional  requirements  (e.g.,  it  must  throw  a  sixteen 
pound  ball  two  hundred  yards)  and  reliance  on  the  repu¬ 
tation  of  the  builder.  The  weapon  goals  were  specified 
in  terms  of  the  mission  it  was  to  serve.  Inherent  in 
this  business  transaction  was  the  trust  that  both  par¬ 
ties  knew  well  enough  what  constituted  a  cannon.  Fur¬ 
ther,  accepted  practices  were  sufficiently  developed  for 
producing  that  cannon  so  that  no  bad  surprises  (such  as 
a  barrel  melting  after  ten  shots)  would  develop.  Wea¬ 
pons  were  simple;  contracts  were  simple.  In  1798,  Eli 
Whitney  sucessfully  applied  a  relatively  new  concept  of 
interchangeable  parts  on  muskets  and  contracted  with 
the  government  to  manufacture  them.  Eli  Whitney  dem¬ 
onstrated  that  planned  attention  to  detail  and  the  use 
of  engineering  tolerances  could  produce  a  product  which 
assembled  on  the  first  try.  Weapon  system  design  took 
its  first  serious  step  into  design  detail.  No  longer 
would  requirements  levied  on  contractors  be  as  they 
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aticr.s  about  predict  component  design  and  engineering 
tolerances  wo -.Id  re  a  commonly  accepted  facet  of  the 
contractual  transacticn. 

Using  this  partial  history,  it  is  ncv.'  possible 
tc  begin  t:  weave  the  historic  development  of  weapon 
system  acquisition  into  the  fabric  of  a  public  agency ' s 
functional  rationalism.  Requirements,  new  as  then,  are 
cf  two  maicr  types.  First,  there  are  required  charac¬ 
teristics  cf  the  product  itself.  Highest  of  these  are 
the  requirements  for  the  mission  tc  be  accomplished, 
followed  by  other  functional  statements  necessary  for 
the  product  to  exhibit  such  traits  as  good  maintain¬ 
ability  and  reliability.  Next  comes  design  details. 
These  specify  the  composition  of  the  product  rather 
than  its  function.  A  second  type  of  requirement  is  one 
specifying  some  type  of  contractual  performance  or  com¬ 
pliance.  This  type  centers  on  the  contractor's  process 
and  not  on  his  product.  In  essence,  it  grew  as  an  amal¬ 
gamation  of  "lessons  learned"  from  prior  developments 
and  ultimately  became  formalized  in  regulations  and 
manuals  specifying  various  management  schemes,  tech¬ 
niques,  and  reporting  systems. 

Functional  rationalism  is  said  to  have  a  defin¬ 
ite  impact  on  goals  because  of  the  preoccupation  with 
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process.  The  Air  Force  weapon  system  acquisition  analog 
to  the  general  term  "goal"  is  the  more  specific  technical 
requirement  -  -  the  first  type  of  requirement  in  the 
above  description.  The  analog  to  the  general  term 
"process"  lies  in  the  government  management  and  report¬ 
ing  systems.  Those  invoked  on  contracts  are  the  second 
type  of  requirement. 

Resuming  with  history,  little  change  occurred 
in  the  military  procured  weapon  systems  during  the  years 
1800  through  1917*  The  development  process  was  general¬ 
ly  left  to  the  private  contractors,  or  done  completely 
by  the  military  in  various  arsenals.  Only  sporadic 
interest  was  shown  by  various  individuals  of  the  Army 
Quartermaster  Corps  or  the  Signal  Corps.  The  function 
of  the  government  agents  was  basically  one  of  procure¬ 
ment,  and  that  of  contractors  was  supplying  a  product 
they  had  already  developed  and  made  production  ready. 

In  the  fall  of  1917.  a  Signal  Corps  Experi¬ 
mental  Laboratory  was  established  at  McCook  Field  (now 
Wright-Patterson  Air  Force  Base)  near  Dayton,  Ohio.  It 
was  intended  to  form  the  nucleus  of  military  research 
and  development  of  experimental  systems,  which  included 
airplanes.  It  grew  and  diversified  during  the  next 
two  decades.  Whether  actually  conducted  by  the  Army 
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or  only  monitered  by  then,  research  into  the  developner. 
of  weapon  systems  was  no  longer  the  exclusive  domain  of 
private  contractors.  Even  at  this  early  time,  the  use 
of  civil  servants  had  become  popular  in  order  to  main¬ 
tain  a  stable  pool  of  experts  in  functional  areas = 
Functional  organizations  became  an  accepted  principle 
during  this  time.  For  example,  the  engine  experts  at 
McCook  Field  were  in  one  shop  and  supported  development 
of  several  aircraft  engine  types  from  that  home  office. 
The  traditional  way  of  building  an  aircraft  during  that 
tine  was  to  use  several  diverse  contractors,  each  super 
vised  by  a  functional  shop,  and  to  somehow  arrange  a 
cooperative  plan  for  all  products  (such  as  engines,  in¬ 
struments,  and  landing  gear)  to  be  sequentially  deliv¬ 
ered  to  the  developing  air-frame  for  assembly. 

The  functional  shops  found  themselves  supervis¬ 
ing  an  ever  more  complicated  situation  as  time  went 
along.  Referring  to  an  earlier  time,  if  one  were  build 
ing  a  musket  using  Eli  Whitney’s  interchangeable  parts, 
he  might  get  the  barrel  from  one  contractor,  the  stock 
from  another,  and  the  trigger  mechanism  from  still  an¬ 
other.  Interface  between  these  parts  could  readily  be 
controlled  by  reference  to  design  detail  drawings  and 
special  emphasis  on  engineering  tolerances.  It  is  im- 


portant  to  note  that  such  interfaces,  even  then,  might 
be  between  different  contractors  as  well  as  between 
parts.  As  long  as  accepted  practices  were  dominant  in 
the  industry,  and  the  interfaces  low  in  number  and  com¬ 
plexity,  assembly  was  accomplished  with  minimal  problem. 
As  airplanes  became  more  complex,  it  became  evident  that 
the  interface  problem  was  no  longer  one  of  basically 
scheduling  and  assembling  all  procured  parts.  This 
growing  problem,  pushed  along  by  power  struggles  among 
the  functional  shops,  led  officials  at  McCook  Field  to 
look  for  a  better  organization  structure.  In  1939 »  the 
first  project  shop  was  established.^  The  project  shop 
took  functional  experts  and  assigned  them  to  specific 
development  programs  under  the  operational  control  of 
a  single  leader.  Although  the  expert  was  often  admini¬ 
stratively  retained  in  his  functional  home  office,  he 
was  operationally  controlled  by  the  project  leader. 
Equally  as  important,  resolution  of  conflicts  between 
functions,  which  often  occurs  at  the  interfaces,  now 
had  a  formal  home  with  the  project  leader,  instead  of 
the  previous  situation  in  which  relative  power  of  the 
functional  offices  prevailed. 

The  Army  now  had  two  principle  weapon  acqui¬ 
sition  functions  at  McCook  Field.  First,  they  were 
involved  in  development  of  airplanes  and  their  compon- 
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ents.  Just  as  importantly,  they  supervised  the  assembly 
of  the  developed  aircraft  in  production .  No  single 
government  office  controlled  both  efforts.  Dual  de¬ 
velopment  and  production  offices  for  each  program  was 
the  rule  and  it  worked  well  for  many  years.  In  the  mid¬ 
forties,  the  B-29  3omber  was  developed.  The  system 
complexity  had  reached  such  a  point  by  this  time  and 
design  and  detail  was  so  great,  that  no  clear  break¬ 
point  between  development  and  production  was  evident. 

In  a  real  sense,  the  integration  problems  of  the  various 
complex  aircraft  systems  were  so  numerous,  diverse,  and 
interrelated,  that  interfaces  normally  worked  during  the 
production  phase  were  being  anticipated  earlier  in  the 
design  phase.  Modern  weapon  development  had  come  of 
age.  Component  design  was  now  accomplished  with  an  eye 
towards  future  interfaces.  Making  this  now  complicated 
development/production  process  work  required  integration 
of  the  dual  program  offices  into  one  -  -  the  first  in¬ 
tegrated  System  Program  Office. 9 

The  period  between  World  War  Two  and  the  early 
1960's  saw  a  constant  battle  between  two  agencies  and 
between  two  concepts.  The  agencies  were  the  budding  Air 
Research  and  Development  Command,  which  was  established 
by  the  Ridenour  Committee  of  the  Air  Force  Scientific 
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Advisory  Board,  and  the  older  Air  Material  Command, 
which  had  previously  supervised  the  early  integrated 
program  offices.  The  old  belief  in  separate  programs 
for  development  and  production  had  already  died.  The 
obvious  question  revolved  around  which  side  of  the  in¬ 
terface  should  control  the  whole  process  -  -  development 
or  production.  The  process  moved  from  the  dual  program 
office  concept  originally  used,  to  a  "team  captaincy" 
concept  of  Air  Force  Regulation  20-10  in  195^*  It  went 
through  the  "Gillette  procedures"  involving  direct  re¬ 
porting  to  the  Air  Staff  in  1955 »  to,  finally,  the  Wea¬ 
pon  System  Management  Study  Group  of  1959  which  rele¬ 
gated  Air  Material  Command  to  a  secondary  role.  The 
question  was  thus  answered  and  the  balance  had  shifted 
to  the  development  side  and  to  the  Air  Research  and  De¬ 
velopment  Command. 

The  two  concepts  at  odds  were  the  polar  extremes 
to  a  question  concerning  who  controlled  the  technical 
experts.  With  the  growing  complexity  of  weapon  systems, 
private  contractors  found  themselves  hiring  an  ever  in¬ 
creasing  number  of  specialized  experts.  Unlike  the 
military,  these  contractors  could  not  simply  assign 
their  excess  talent  to  basic  research  when  not  needed  on 
a  contract,  they  either  found  another  contract  or  fired 
the  excess.  This  often  meant  firing  excellent  talent 
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simply  because  no  current  contract  needed  that  partic¬ 
ular  talent  at  that  time.  Contractors  diligently  search¬ 
ed  for  a  way  to  maintain  a  stable  labor  pool  of  experts 
and  soon  came  to  covet  the  basic  research  and  supplemen¬ 
tary  technical  support  on  various  contracts  given  by  the 
functional  shops  at  McCook  Field.  The  functional  shops 
at  McCook  Field,  however,  were  deeply  entrenched  in  the 
bureaucracy  by  the  late  1940 's.  In  the  face  of  in¬ 
creasingly  complex  tasks,  these  shops  generated  pressure 
for  larger  increases  in  people  and  the  ability  to  offer 
inducements  sufficient  to  hire  people  away  from  industry 
in  critical  areas.  Neither  side  scored  a  clear  victory 
in  this  battle  but  it  led  to  limited  use  of  two  new  ar¬ 
rangements  still  used  today.  The  first  idea  was  to 
try  a  shift  of  the  daily  engineering  burden  of  control¬ 
ling  a  development  and  production  from  the  government 
program  to  one  single  integration  or  "prime"  contractor. 
Previously,  the  Air  Force  (which  was  officially  con¬ 
stituted  from  the  Army  Air  Corps  in  1947)  had  matured 
from  dual  control  to  one  central  point  of  control  for 
its  development  programs  but  it  still  did  the  engineer¬ 
ing  integration  work  itself.  Now  a  contractor  was  hired 
who  was  to  have  total  system  performance  responsibility 
for  the  component  building  and  integration  of  the  weapon 
system.  The  government  program  office  still  existed  and 
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exercised  final  authority,  but  its  role  shifted  towards 
management  by  exception. 

The  second  approach  occurred  in  response  to  the 
perceived  missile  gap  of  the  early  1950’s  and  our  des¬ 
peration  to  build  an  intercontinental  ballistic  missile 
in  the  shortest  time  possible .  The  Strategic  Missiles 
Evaluation  Committee  of  195^  recommended  a  technical 
support  engineering  contractor  be  hired  to  advise  the 
government  on  development  of  a  missile  placed  on  contrac 
with  a  prime  contractor.  Their  rationale  for  modifying 
the  new  prime  contractor  arrangement  was  set  forth: 

After  considerable  discussion  and  negotiation, 
the  committee  rejected  the  use  of  a  single  prime 
contractor  for  the  program  on  the  grounds  that  no 
single  industrial  organization  possessed  the  nec¬ 
essary  range  of  skills  and  over-all  capability 
required  to  perform  the  task. 11 

This  type  of  technical  consulting  company  was  considered 
to  be  more  flexible  than  a  prime  contractor  because  its 
focus  was  on  solving  short-run  technical  problems  and 
not  on  the  over-all  development  of  a  particular  weapon 
system.  Thus,  such  a  company  could  bid  for  small,  but 
highly  technical  consulting  roles  on  many  programs  and 
therefore  not  suffer  when  the  development  cycle  of  any 
particular  program  had  run  its  course.  As  one  can  see, 
this  is  the  private  contractor  equivalent  of  the  govern- 
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ment  functional  shops.  Proponents  of  this  type  of  com¬ 
pany  argued  that  civil  service  tenure  guarantees  and  low- 
relative  governmental  salaries  were  already  turning 
functional  shops  into  mediocre  talent  pools  filled  with 
people  who  learned  their  functional  speciality  years 
before  and  felt  no  pressure  to  stay  current.  The  priv¬ 
ate  consulting  company,  on  the  other  hand,  would  be  more 
flexible  because  it  could  immediately  recruit  in  spe¬ 
cific  areas,  pay  the  premium  salaries  necessary'  to  hire 
scarce  talent,  and  motivate  employees  to  stay  current 
through  its  ability'  to  fire  them  simply  and  quickly  for 
poor  performance.  The  first  contractor  of  this  type 
was  Ramo -Wooldridge  Corporation. 

Use  of  a  prime  contractor  had  reduced  direct 
government  engineering  to  technical  management  by  ex¬ 
ception.  Further,  it  used  government  funds  to  maintain 
the  true  technical  expertise  in  a  program  in  the  hands 
of  their  contractual  adversaries.  This  was  not  con¬ 
sidered  altogether  satisfactory  and  the  subsequent  rise 
of  technical  consultant  companies  was  hoped  to  be  an 
effective  balance.  Over  time,  criticism  of  these  con¬ 
sultants  also  grew  due,  in  part,  to  the  conviction  that 
the  supposedly  captive  technical  advisors  had  allowed 
their  professional  considerations  to  override  their 
commitments  to  serve  government  goals.  Where  a  program 
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might  be  interested  in  an  acceptable  engineering  change 
which  was  inexpensive,  the  technical  consultant  might 
press  for  a  more  technically  elegant  alternative  despite 
its  cost.  A  Ph.D.  in  nuclear  engineering  does  not  want 
to  measure  radioactivity  on  a  watch  dial.  This  paroch¬ 
ialism,  coupled  with  their  virtually  unassailable  tech¬ 
nical  base,  was  allegedly  used  to  overcome  government 
control  of  a  program.  Using  Herbert  Simon's  terms, 
their  overpowering  control  of  the  facts  was  their  lic¬ 
ense  to  judge  values.  Modem  Air  Force  weapon  acquisi¬ 
tion  still  uses  a  mixture  of  all  three  approaches. 

John  F.  Kennedy's  election  in  i960  brought 
Robert  S.  McNamara  to  the  job  of  Secretary  of  Defense. 
During  the  subsequent  years,  there  was  a  dramatic  in¬ 
crease  in  the  scope  of  the  Department  of  Defense  Re¬ 
search  and  Evaluation  Office's  involvement  in  the  mili¬ 
tary  management  process.  This  period  was  marked  with 
increasingly  centralized  control  and  the  institution  of 
rigorous  management  systems  to  control  the  acquisition 
process.  The  introduction  of  McNamara  brought  a  quick 
restructuring  of  Air  Force  acquisition.  Basic  research, 
that  not  pointed  at  a  particular  product,  was  assigned 
to  a  newly  created  Office  of  Aerospace  Research. 

Air  Force  development  was  assigned  to  the  Air  Force 


Systems  Command  and  the  Air  Material  Command  was  re¬ 
chartered  as  the  Air  Force  Logistics  Command.  An  out¬ 
growth  of  the  1959  Weapon  System  Management  Group  find¬ 
ings  was  the  assignment  of  all  responsibilities  for 
acquisition  (control  of  both  development  and  production 
contracts)  to  the  Air  Force  Systems  Command.  This  was 
fleshed  out  in  a  new  weapon  system  acquisition  concept 
which  was  documented  in  a  "375"  series  of  regulations, 
manuals,  and  pamphlets.  The  375  series  was  extensive 
in  its  coverage  of  the  processes  a  System  Program  Of¬ 
fice  must  go  through  in  a  development,  and  it  detailed 
a  growing  list  of  collateral  systems  for  configuation 
control,  program  control,  and  management  reporting. 

Further  elaboration  and  modification  of  the  man¬ 
agement  system  occurred  in  1971  with  Department  of  De¬ 
fense  Directive  5000.1.  A  principle  purpose  of  this 
directive  was  to  correct  the  high  degree  of  central¬ 
ization  in  decision  making  started  in  the  McNamara  era. 
This  directive  specified  de-centralization  and  outlined 
how  that  would  work.  It  added  information  on  manage¬ 
ment  discipline,  and  developed  its  own  regulations  out¬ 
lining  program  managers'  functions  during  the  various 
phases  of  a  program  life  cycle. ^  The  Air  Force  imple¬ 
mented  5000.1  in  an  "800  series"  of  regulations,  manuals, 
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and  pamphlets  supplanting  the  earlier  375  series.  Fur¬ 
ther  codification  of  the  weapon  acquisition  process  into 
life  cycle  steps,  the  specific  delegation  of  responsi¬ 
bilities  and  authority,  and  various  management  systems 
are  all  included  in  the  800  series.  As  the  process  has 
matured,  the  sequential  action  chain  has  become  more 
and  more  functionally  rationalized  both  in  terms  of  or¬ 
ganizational  roles  and  in  systematic  steps  required  in 
a  given  program  development.  Contests  of  power  between 
commands  have  been  somewhat  smoothed,  authority  of  com¬ 
mand  levels  clarified,  and  transition  between  program 
xife  cycle  phases  delineated.  Further,  as  the  process 
has  become  increasingly  defined,  systematic  approaches 
to  developmental  problems  have  risen.  Cost,  being  a 
major  problem  in  development  programs  extended  over  time, 
has  received  its  share  of  attention.  The  concept  of 
"life-cycle  cost"  (which  requires  consideration  of  main¬ 
tenance,  spare  part  and  other  costs  as  well  as  pro¬ 
duction  cost)  has  appeared.  "Design-to-Cost"  emphasis 
on  designing  towards  some  target  production  cost  has 
become  popular.  In  each  area,  the  problem  has  been 
analyzed  and  integrated  into  the  already  established 
development  system. 
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A  Conclusion  on  Requirements 

The  focus  on  product  technical  requirements  has 
not  received  the  systematic  attention  as  has  that  on 
process.  Strayer  and  Lockwood  say  about  this  problem: 


The  existing  process  turns  on  the  main  valve  (the 
requirement  itself)  but  it  does  not  yet  address,  i 
sufficient  detail,  what  should  be  included  in  the 
content  pipeline. ^3 


It  is  the  thesis  of  this  dissertation  that  a  broad  and 
flexible  term  must  be  defined  tc  link  high  order  concep 
tual  program  goals  to  specific  design  detail.  Under 
this  umbrella  term  a  taxonomy  of  terms  is  necessary  and 
some  broad  ground  rules  must  be  established  controlling 
the  build-up  of  content  in  each  category.  This  term 
will  allow  emphasis  of  the  step  by  step  relationship  of 
objectives  as  they  are  defined  in  increasing  detail. 

It  will  serve  as  a  foil  with  which  process  oriented 
management  systems  are  parried  to  the  ultimate  end  of 
achieving  a  more  balanced  style  of  weapon  system  acqui¬ 
sition.  The  term  used  will  be  the  requirement. 


>*. 


29 


CHAPTER  CNE  ENDNOTES 


1.  See  Peck  and  Shearer's  The  Weapons  Acquisition 
Process:  An  Economic  Analysis  (Bibliography 
Number  39 

2.  Reference  Office  of  Federal  Procurement  Policy's 
report  "Major  Acquisitions  -  A  Discussion  of  the 
Application  of  OMB  Circular  No.  A  -  109",  page  5 
(Bibliography  number  51  ) . 

3-  Excerpted  from  General  Holzapple's  address  "Air 
Force  System  Command  Report  375  -  1  Number  53", 
page  1  (Bibliography  number  18  ) . 

A.  See  Herbert  Kaufman's  "Emerging  Conflicts  in  the 
Doctrines  of  Public  Administration"  (Bibliography 
number  25 ) . 

5.  See  Frederick  Mosher's  Democracy  and  the  Public 
Service  (Bibliography  number  35  ) . 

6.  Reference  Lloyd  Nigro's  article  "Administrative 
Behavior  and  Self-Rationalized  Man"  on  page  29  of 
Political  Science  Journal ,  Volume  5  (Bibliography 
number  JS  T"»  ~ 

7.  See  Herbert  Simon's  book  Administrative  Behavior, 
page  46  (Bibliography  number  47  )"! 

8.  See  Putnam's  "The  Evolution  of  Air  Force  System 
Acquisition  Management",  page  2  (Bibliography 
number  44  )  . 

9.  Ibid,  page  3. 

10.  Ibid,  page  5. 

11.  Ibid,  page  8. 

12.  Reference  Charles  Hoskins'  "Analysis  of  Engineering 
Transfer  of  Acquisition  Systems",  page  5  (Bibliog¬ 
raphy  number  19  ) . 

13.  See  Daniel  Strayer  and  Lyle  Lockwood, *s  article  "What 
Are  We  Buying  Here?,  page  2  (Bibliography  number  52) . 


CHAPTER  TWC 


ACr-ir_'.IC 


Academia  ana  Technical  Management 

The  purposes  of  academic  study  are  generally 
aligned  wi  „h  the  growth  of  knowledge  while  those  of 
practical  management  are  with  controlling  alternate 
futures  based  on  past  experiences.  When  one  first 
studies  an  emerging  practical  problem  area,  the  interest 
of  academic  knowledge  often  coincide  with  concerns  of 
practical  management.  The  pioneering  work  of  authors 
like  Gulick  and  Urwick  served  for  many  years  as  both 
an  academic  base  for  study  and  a  practical  guide  for 
operation.  In  weapon  system  acquisition,  the  pioneering 
work  of  Peck  and  Shearer  has  had  a  similar  effect  in 
establishing  uncertainty  as  a  key  area  of  interest  both 
of  academic  and  practical  observers.  There  is  no  argu¬ 
ment  that  the  academic  concepts  of  uncertainty  and  the 
practical  consequences  seen  by  managers  need  further 
study.  A  more  global  question  concerning  weapon  system 
acquisition  epistemology  is  raised. 

A  discussion  of  management  epistemology  was 
raised  by  Kozmetsky  and  Cunningham  in  a  197^  paper. 

Their  paper  was  intended  to  "provide  a  framework  to  link 
in  a  unique  body  of  science  the  knowledge  acquired 
through  both  the  academic  management  and  the  practical 
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management."!  Key  to  this  dissertation  was  their  recog¬ 
nition  that  a  "theory  of  the  nature  and  grounds  of  know¬ 
ledge  with  reference  to  its  limits  and  validity"^ 

(their  definition  of  epistemology)  depended  on  both 
academic  and  practical  conceptual  constructs.  They 
recognized  that  each  of  these  types  of  construct  were 
already  defined  in  different  functional  contexts  and 
that  many  already  had  their  own  sub-epistemologies. 

Thus  academic  disciplines  of  business  administration, 
education,  engineering,  law,  and  public  affairs  must 
relate  in  practical  environments  of  government,  business, 
and  unions,  to  name  a  few.  The  diverse  conceptual  con¬ 
structs  and  sub-epistemologies  requires  assimilation 
of  pertinent  parts  of  each  into  partial  management  epi¬ 
stemologies.  In  this  context,  the  practical  and  academic 
concerns  on  uncertainty  form  only  a  small  part  of  an 
assimilated  epistemology,  just  as  if  one  used  only 
parts  of  the  academic  functional  constructs  with  a 
limited  range  of  practical  experiences.  While  this 
dissertation  does  not  chart  the  boundaries  of  a  weapon 
system  acquisition  epistemology,  it  adds  another  im¬ 
portant  element  which  is  the  study  of  technical  require¬ 
ments  . 
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Early  Studies  -  -  Uncertainty  and  Complexity 

Peck  and  Shearer  set  the  pattern  for  subsequent 
writers  in  their  oblique  analysis  of  requirements  ir. 
their  book,  The  Weapons  Acquisition  Process  -  -  An 
Economic  Analysis ■ 3  Notably,  the  term  "requirement" 
does  net  appear  in  the  index.  The  end  points  of  the 
weapon  acquisition  process  probably  seemed  too  clear 
for  discussion.  One  starts  with  a  single  need  state¬ 
ment;  one  is  satisfied  only  when  a  product  is  delivered. 
Their  attention,  therefore,  centers  on  the  process 
of  taking  the  product  from  one  extreme  to  the  other. 

The  prevailing  characteristic  of  the  process  is  that  a 
few  broad  requirements  grow  to  many  specific  ones. 

This  growth  of  requirements  takes  a  product  from  un¬ 
certainty  to  certainty.  The  process  of  taking  require¬ 
ments  from  one  extreme  to  another  involves  a  series  of 
decisions  over  contemplated  actions: 


. . . .we  define  uncertainty  as  the  relative  unpre¬ 
dictability  of  the  outcome  of  a  contemplated 
action.^ 


Peck  and  Shearer  maintain  that  uncertainty  can  exist 
in  two  basic  forms.  External  uncertainty  is  the  uncer¬ 
tainty  of  need  or  strength  of  support  coming  from  out¬ 
side  the  program.  It  reflects  updated  assessments  of 
the  threat,  desirability  relative  to  technical  break- 


throughs,  and  relative  priorities  with  other  programs 
for  allocation  of  funds.  Internal  uncertainty  is  that 
which  is  caused  by  the  facing  of  technical  difficulties 
and  complexities  within  the  program.  It  is  the  iter¬ 
ations  and  blind  alleys  one  sees  when  trying  to  fit 
numerous  complicated  requirements  into  one  puzzle.  Feck 
and  Shearer  state  that  this  is  a  major  contributor  to 
technical  difficulties  and  have  labeled  this  type  of 
internal  uncertainty  as  complexity: 

....yet  if  the  major  effort  is  engineering,  it 
has  become  increasingly  complex  engineering. 

Indeed  the  most  striking  feature  of  current 
weapon  system  programs  appears  not  so  much  to 
be  the  magnitude  of  the  state  of  the  art  advances 
attempted  as  their  tremendous  complexity. 5 

Some  requirements  get  specified  simply  as  a  consequence 
of  the  higher  requirements  they  meet.  For  instance, 
significant  portions  of  an  airframe  can  be  designed 
using  standard  design  concepts,  materials  and  fasteners 
if  the  environmental  performance  requirement  has  been 
previously  met.  Other  requirements  are  not  so  simple. 
These  are  what  Peck  and  Shearer  would  call  "technical 
problems".  In  continuing  the  above  quote,  they  say: 

This  complexity  creates  uncertainty  in  at  least 
three  different  ways:  in  total  number  of  technical 
problems  involved,  in  the  inter-relationship  between 
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technical  problems,  and  in  the  reliability  re¬ 
quirements  generated  by  the  sheer  number  of 
individual  components. 6 

Requirements  have  thus  been  seen  for  their  character¬ 
istics  of  uncertainty  and  complexity,  and  have  been 
singled  out  for  particular  attention  when  they  -  - 
individually  or  in  groups  -  -  cause  technical  problems. 
Peck  and  Shearer's  perspective  centering  on  contemplated 
action  included  necessary  elements  of  the  definition  of 
a  requirement  because  only  a  culminated  contemplated 
action  can  be  forceful  in  a  contract  and  Peck  and 
Shearer's  analysis  uses  outcomes  of  contracts  as  evi¬ 
dence  supporting  their  positions.  Requirements  are 
the  expression  of  a  culminated  contemplated  action. 

Later  Years  -  -  An  Oblique  Interest  Continued 

The  tendency  of  looking  at  requirements  only 
when  they  cause  technical  problems  or  exhibit  the  re¬ 
sults  of  uncertainty  and  complexity,  has  been  carried 
forward  by  other  researchers.  In  a  more  positive  per¬ 
spective,  these  authors  have  tried  to  anticipate  areas 
where  problems  would  likely  occur  and  focus  on  a  sub¬ 
set  of  those  most  crucial  to  program  success.  These 
crucial  and  problem  prone  areas  are  listed  as  "tech¬ 
nical  performance  parameters"  and  are  tracked  from 
early  in  a  development.  One  researcher  couples  this 
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with  a  "subjective  probability  approach"  (Timson, 

1968) .7  This  approach  hinges  on  the  premise  that  al¬ 
though  subjectively  done,  measures  of  uncertainty  can 
be  taken  over  time.  An  argument  is  advanced  that  "pro¬ 
gress  is  characterized  as  a  reduction  in  uncertainty" , 
thus  progress  can  be  measured  on  identified  technical 
problems.  A  major  assumption  in  advocating  such  an 
approach  is  that  a  project  can  be  expressed  in  terms  of 
its  critical  parameters  and  that  a  combination  of  rou¬ 
tine  attention  on  straightforward  requirements  and  in¬ 
tensive  attention  on  critical  requirements  will  lead  to 
a  successful  development.  This  process  seemingly  covers 
the  universe  of  requirements,  but  Peck  and  Shearer’s 
concerns  over  complexity,  and  especially  "the  inter¬ 
relationship  between  technical  problems"  argue  that  the 
problem  is,  perhaps,  more  than  the  sum  of  its  indivi- 
ual  parts.  While  one  can  argue  that  a  formalized  process 
of  gradiated  attention  on  selected  problems  is  one  useful 
management  tool,  he  cannot  argue  that  this  process  is  a 
definative  answer  to  the  nature  of  requirements  growth. 

Control  systems  have  always  been  popular  as  a 
research  topic  due,  in  part,  to  the  fact  that  they  re¬ 
sult  in  immediately  useful  conclusions.  Meiners  reviewed 
Peck  and  Shearer's  work  with  the  intent  of  describing  a 
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system  to  control  changes  that  occur  in  the  requirements 
process  from  concept  to  implementation.®  Inherent  in 
his  approach  is  the  assumption  that  program  changes  are 
anomolies  in  the  normal  flow  of  requirements  evolution. 
Peck  and  Shearer  attributed  such  program  changes  to  pro¬ 
gram  uncertainty,  contractor  optimism  in  bidding,  and  a 
lack  of  a  sense  of  urgency.  This  led  to  schedule  slips, 
funding  slips,  and  ultimately  requirements  changes.  The 
conclusions  of  Peck  and  Shearer  were  the  result  of  a 
large  amount  of  data  accumulated  from  previous  Harvard 
Business  School  studies,  and  in  particular,  an  economic 
analysis  of  nineteen  programs  by  the  authors  and  their 
research  team.  Meiners  uses  questionnaires  from  program 
leaders  and  contracting  officers  of  twenty-five  pro¬ 
grams.  While  his  sample  is  more  extensive,  the  depth 
of  analysis  is  not  as  deep.  He  coi  .xudes  that  the  four 
main  causes  of  program  change,  in  order  of  importance, 
are : 

1)  .  changes  in  operational  requirements  imposed 

on  the  system, 

2)  .  incomplete  early  plans  and  technical  defin¬ 

ition, 

3)  .  changes  in  program  funding,  and 

4)  .  changes  in  the  program  to  accommodate  new 

state  of  the  art  development. 

Reviewing  Peck  and  Shearer's  previous  definition  of  an 
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internal  and  external  condition  of  uncertainty,  one  sees 
fundamental  support  by  Meiners  over  its  role  in  affecting 
programs.  Classically,  Meiners'  causes  (1),  (3)»  and  (4) 
are  external  uncertainties  while  (2)  is  just  as  classic 
an  example  of  internal  uncertainty'.  Recasting  Meiners' 
list  of  causes  into  terms  involving  requirements,  one 
sees  the  major  causes  of  program  changes  to  be  either  an 
externally  forced  change  to  what  a  program  had  previously 
considered  a  firm  requirement,  or  the  lack  of  definition 
by  a  program  as  to  what  actually  constituted  its  require¬ 
ments  in  the  program.  A  particular  salient  point  con¬ 
cerning  incomplete  early  technical  definition,  is  that 
such  internally  derived  requirements  are  usually  the 
first  type  to  require  statement  in  different  terms  and 
documents  than  the  imposed  operational  requirements.  In 
most  cases,  operational  requirements  are  specified  by 
agencies  external  to  the  program  and  are  an  expression 
of  high  order  conceptual  needs.  Initial  technical  def¬ 
inition  is  more  pointed  at  specific  functional  charac¬ 
teristics  of  hardware  and  even  includes  some  technical 
detail.  Considering  Meiners’  conclusion  in  this  light, 
one  is  led  to  question  the  problem  as  being  more  than 
the  sum  of  the  parts.  In  this  case,  the  different 
languages  used  between  imposed  operational  requirements 
and  derived  functional  and  detail  requirements  can  act¬ 
ually  exacerbate  each  of  the  individual  relationships. 
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Several  studies  have  dealt  with  the  subject  of 
uncertainty  but  did  not  deal  with  the  effects  of  require¬ 
ment  growth.  As  was  previously  covered,  requirements 
growth  is  ideally  envisioned  as  an  orderly  process  which 
is  disrupted  by  forces  including  those  labeled  as  ex¬ 
ternal  and  internal  uncertainty.  The  bulk  of  the  un¬ 
certainty  studies  focus  on  one  of  the  consequences  of 
disorderly  growth,  namely  unanticipated  cost  growth. 

Sponsler,  Gignoux,  and  Rubin?  attempted  to 
find  some  parametric  estimators  of  program  costs  for 
fighter  aircraft.  Using  historical  data  from  twenty- 
three  completed  fighter  programs,  they  generated  a  re¬ 
gression  equation  using  aircraft  empty  weight,  wing 
thickness  ratio,  and  avionic  power  as  independent  vari¬ 
ables.  Despite  mixed  results  on  two  still-developing 
aircraft,  the  equation  appears  to  do  as  well  as  any 
previous  estimator.  A  review  of  their  parameters  reveals 
an  interesting  relationship.  Empty  weight  is  a  direct 
indicator  of  size.  It  has  long  been  used  as  a  measure 
of  both  uncertainty  and  complexity.  Avionic  power 
represents  ?  modem  day  addition.  Where  large  scale 
electronic  integration  has  prevailed,  both  weight  and 
volume  have  often  decreased  while  functional  complexity 
has  risen  sharply.  A  small  ratio  of  wing  thickness  to 
wing  chord  is  an  indicator  of  "increased  technical 
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sophistication".^  All  three  terms  are  thus  highly 
linked  to  technical  uncertainty  and  complexity. 

One  can  conclude  from  the  writings,  to  date, 
that  uncertainty  and  complexity  cause  problems  in  a 
program's  development,  and  that  this  is  likely  seen  in 
its  requirement  growth  pattern.  Further,  the  consequen¬ 
ces  of  such  disorderly  growth  is  shown  in  areas  of  per¬ 
formance,  schedule,  and  cost.  A  disquieting  note  to 
this  conclusion  is  sounded  by  Henry. 11  His  look  at 
initial  conditions  of  weapon  systems  as  predictors  of 
cost,  used  the  early  development  budget  to  predict  sub¬ 
sequent  program  cost.  He  intended  this  parameter  to 
serve  as  a  surrogate  for  technical  uncertainty,  believ¬ 
ing  that  programs  embarking  on  the  most  uncertain  de¬ 
velopment  paths  would  have  the  highest  initial  develop¬ 
ment  budgets.  The  study  results  showed  no  significant 
relationship.  Henry  did,  however,  note: 


It  may  be  entirely  possible  that  the  definition  of 
development  investment  is  inadequate  to  the  task  of 
measuring  technical  uncertainty.  Despite  the  fact 
that  a  majority  of  programs  (40  of  48)  met  or  sur-^ 
passed  the  performance  goals  set  for  them,  and  that 
the  "science"  of  predicting  what  is  feasible  may  be 
more  efficient  than  the  "art"  of  estimating  cost  or 
schedule  outcomes,  one  should  be  reluctant  to  sur¬ 
mise  that  developmental  effort  has  less  effect  on 
project  success  than  other  program  variables.12 
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Perhaps  Henry's  intuition  that  development  cost  reflects 
technical  uncertainty  can  be  sustained  with  the  addition 
of  a  single  word.  It  is  highly  possible  that  perceived 
technical  uncertainty  is  met  with  higher  initial  devel¬ 
opmental  budgets  and  that  the  perceptions  were  wrong. 

The  study  is  not  persuasive  enough  to  refute  the  wealth 
of  other  findings  which  support  the  relationship  of  un¬ 
certainty  and  developmental  problems. 

A  more  direct  study  of  uncertainty  and  cost  was 
the  entropy  model  developed  by  Martin. ^3  The  basic  prem¬ 
ise  of  this  model  was  that  a  thermodynamic  law  actually 
modeled  information  growth: 


The  expression  has  been  defined  as  a  measure  of 
disorder  in  a  closed  system.  This  definition  has 
to  be  redefined.  Entropy  is  a  measure  of. the  a- 
mount  of  information  in  a  system;  in  particular,  it 
encompasses  the  number  of  choices  available  to  a 
decision  maker.  Entropy  relates  to  the  degree. of 
randomness  of  the  information,  not  to  informational 
efficacy.  As  entropy  increases,  information  in¬ 
creases,  uncertainty  increases,  freedom  of  choice 
increases,  but  the  informational  efficacy  decreases 
as  related  to  the  specific  source.  In  accordance 
with  the  second  law  of  thermodynamics,  the  tendency 
is  for  the  entropy  in  a  system  to  always  increase. 14 


Adding  to  this  basic  definition,  Martin  concludes  that 
uncertainty,  being  directly  linked  to  entropy: 


increases  in  direct  proportion  to  the  number  of  un¬ 
knowns  involved  and  the  distance  in  the  future  of 
the  contemplated  events.  Thus  uncertainty  is  a 
direct  function  of  time. 15 


i 


4-1 


This  leads  Martin  to  measure  relative  uncertainties 
among  programs  by  charting  the  size  of  their  relative 
decision  trees:  the  more  choices  for  alternatives,  the 
more  entropy  and  hence  the  more  uncertainty.  The  Martin 
model  is  intended  to  explore  the  conceptual  relation¬ 
ships  of  cost  and  uncertainty  and  it  concludes: 

The  conclusion  emerged  that  cost  and  risk  analysis 
should  be  combined  into  cost  uncertainty  analysis, 
and  each  aggregate  cost  estimate  should  include  a 
section  which  evaluates  cost  uncertainties .16 

The  Martin  model  was  subsequently  tested  using  a  Delphi 
method  to  reconstruct  the  decision  trees  of  the  Short 
Range  Attack  Missile. ^7  The  conclusion  was  that  some 
statistical  support  was  found  for  the  theory.  Since 
however,  this  single  sample  asked  program  people  to  re¬ 
cast  an  already  completed  program,  there  is  some  concern 
that  their  recollections  might  well  be  a  form  of  self- 
fulfilling  prophesy  -  -  high  cost  areas,  in  retrospect, 
would  be  seen  as  results  of  uncertainty. 

An  attempt  was  made  to  expand  the  Glover  iteration 
of  the  Martin  model  to  the  F-5E  aircraft. 

This  attempt  provided  a  cost  variance  of  over  900 
percentum  from  actual  results  and  caused  the  authors  to 
question  the  Delphi  method  for  testing  entropy. 

Evaluation  of  the  Martin  model  leads  a  person  to  con- 


42 


elude  that  it  is  not  an  especially  good  vehicle  for  eval¬ 
uating  requirement  growth  per  se .  Uncertainty  is  a  phen¬ 
omenon  that  manifests  itself  differently  on  cost,  sched¬ 
ule,  and  performance.  The  contention  that  requirements 
grow  from  uncertainty  to  certainty  is  so  logical  as  to  be 
a  truism.  Martin  postulates  growing  uncertainty.  The 
conciliation  lies  in  the  different  perspectives.  While 
there  is  an  increasing  number  of  alternatives  in  a  devel¬ 
opment,  and  while  effort  on  each  means  increased  engin¬ 
eering  time  and  expense,  these  alternatives  are  worked  to 
conclusion.  So  while  cost  increases,  requirements  are 
becoming  firmer.  As  cost  uncertainty  increases,  require¬ 
ment  uncertainty  decreases.  Use  of  the  Martin  model  to 
investigate  requirement  growth,  therefore  would  require 
first  a  better  validation  of  the  model  (in  light  of  its 
mixed  results)  and  then  a  validation  of  the  inverse  re¬ 
lationship  between  cost  and  requirement  growth  uncertain¬ 
ty.  While  this  can  be  a  valuable  exercise  for  future 
researchers,  the  current  research  base  makes  it  a  highly 
tenuous  and  indirect  alternative. 

Learning  Analogy  Used  in  Understanding  Requirements 

If  analysis  of  the  direct  academic  work  on  weapon 
system  acquisition  has  proven  an  unsatisfactory  frame¬ 
work  for  understanding  requirements,  one  must  ask  about 
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the  use  of  potential  analogies  frorr.  other  academic 
fields.  Martin  used  the  field  of  thermodynamics  effec¬ 
tively  to  model  cost  uncertainty.  A  potentially  valid 
field  for  evaluating  requirement  growth  is  the  area  of 
learning  theory.  Indeed,  the  ultimate  definition  of  a 
program,  from  initial  concept  to  final  product,  is  in¬ 
herently  a  result  of  learning.  The  mainstream  of  learn¬ 
ing  theory  contains  a  concept  called  "attainment"  : 

Attainment  refers  to  the  process  of  finding  pre¬ 
dictive  defining  attributes  that  distinguish  ex¬ 
emplars  from  non-exemplars  of  the  class  one  seeks 
to  discriminate .19 

A  principle  objective  of  learning  theory  is  to  put  or¬ 
der  into  observation.  A  fundamental  tool  is  the  con¬ 
cept.  One  observes  several  instances  of  an  interesting 
phenomenon  and  sees  that  there  is  a  uniquely  common 
group  of  characteristics  which  differentiate  that  group 
from  other  close  ones.  This  is  the  attainment  process. 
The  sub-set  as  defined  by  its  common  group  of  character¬ 
istics  is  labeled  with  a  term  -  -  that  term  being  the 
conceptual  equivalent  for  listing  all  the  characteris¬ 
tics.  A  term  or  concept  is  thus  attained  and  retained 
by  one's  recognizing  a  mutually  exclusive  arrangement  of 
characteristics  which  alone  define  that  concept.  How 
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one  attains  and  retains  the  concept  in  memory  is  open 
to  some  conjecture  between  two  different  schools  of 
thought.  The  conflict  first  became  heated  in  the  late 
eighteen  hundreds  between  the  Wundtian  Elemental  and 
Gestalt  factions.  The  Elemental  school  forwarded  the 
proposition  that  concepts  were  learned  independently  cf 
associations  with  other  concepts.  Thus  through  rote 
memory,  one  learned  and  retained  the  defining  charac¬ 
teristics  of  a  concept.  The  Gestalt  school  proposed 
that  learning  and  memory  depended  on  the  relationship 
cf  the  concept  with  concepts  already  retained.  One 
school  proposes  concepts  with  clear  con' eptual  bound¬ 
aries  and  emphasizes  detailed  study  of  those  boundaries 
to  the  exclusion  of  all  else.  The  second  school  pro¬ 
poses  that  concept  boundaries  are  not  sc  clear.  Con¬ 
cepts  are,  in  fact,  clustered  in  many  patterns  with 
other  concepts,  much  as  in  the  logic  associated  with 
venn  diagrams.  Thus,  understanding  and  remembering  a 
concept  must  occur  in  association  with  the  other  re¬ 
lated  concepts.  While  many  scholars  freely  borrow  from 
both  schools,  no  single  eclectic  school  has  emerged: 

At  the  centre  of  all  of  these  is  the  basic  Gestalt 
issue,  by  no  means  resolved  by  the  middle  of  the 
20th  century,  of  empty  hookups  versus  meaningful 
organ! zation . 20 


In  weapon  acquisition,  diverse  operational  needs 
coalesce  around  one  integrated  but  gross  concept  of  a 
weapon  system.  It  is  important  to  recognize  that  a 
weapon  system  is  conceived  specifically  as  an  answer  to 
a  combination  of  important  needs  and  net  as  a  moderni¬ 
zing  innovation  sans  specific  mission  requirements,  h'c 
aircraft  is  built  simply  because  it  is  time  for  a  new 
model  as  is  done  with  cars  in  Detroit.  Once  these  needs 
are  set,  a  research  and  development  process  occurs  tc 
obtain  definition  of  requirements  which  will  satisfy 
higher  needs.  Requirements  beget  requirements.  Al¬ 
though  higher  requirements,  they  do  limit  the  alterna¬ 
tive  range.  A  requirement  is  a  formally  expressed  con¬ 
cept.  What  the  process  therefore  contains  is  a  hier¬ 
archy  of  concepts,  each  constraining  the  lower  ones. 

The  process  of  finding  lower  alternatives  is  generally 
done  with  some  form  of  satisficing.21  As  Martin  showed, 
alternatives  increase  greatly  as  a  program  progresses 
while  generally  the  designers  do  not,  thus  satisficing 
is  more  or  less  forced  on  a  program. 

Requirement  growth  is  net  only  a  process  of 
sorting  alternatives  in  a  hierarchial  framework.  Work 
of  previous  authors  cited  (Peck  and  Shearer,  Meiners, 
Sponsler,  to  name  a  few)  technical  complexity  as  a  major 


factor  in  program  development.  Peck  and  Shearer's  list 
of  three  types  of  uncertainty  caused  by  complexity  es¬ 
tablished  interrelation  between  technical  problems 
as  one  particular  type.  Complexity,  in  part,  is  seen 
to  be  a  development  problem  and  is  seen  as  one  of  asso¬ 
ciation  of  requirements  causing  technical  problems.  Th 
problems  associated  with  combining  technical  require¬ 
ments  is  thus  not  simply  a  summation  of  the  individual 
problems.  They  more  accurately  fit  the  description  of 
a  Gestalt: 

When  spatial,  visual,  auditory,  or  intellectual 
processes  are  such  as  to  display  properties  other 
than  could  be  derived  from  the  parts  of  summation, 
they  may  be  regarded  as  unities  illustrating  what 
we  mean  by  Gestalten.22 

This  perspective  leads  directly  to  the  premise  that  un¬ 
derstanding  of  the  weapon  acquisition  process  will  re¬ 
quire  not  only  a  clear  definition  of  requirement  types, 
but  also  an  understanding  of  the  relationships  between 
requirement  types. 23 
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CHAPTER  THREE  -  -  THE  CONCEPTUAL  MODEL 
System  Acquisition 

Weapon  acquisition  history  has  been  a  process 
of  evolution  from  a  fragmented  military  buying  system 
involving  several  organizations  into  a  single  developmen 
and  buying  group  unified  under  one  command.  The  term. 
"System  Program  Office"  was  given  this  type  of  group 
and  it  had  the  following  characteristics: 

1) .  the  responsibility  for  development  and 

potential  acquisition  of  an  entire  system 
which  includes  ground  test  equipment,  train¬ 
ing  and  technical  manuals,  simulators  and 
all  other  equipment  and  plans  needed  to  acquire 
and  integrate  the  basic  into  the  existing  force 
structure,  and 

2) .  the  major  autonomy  in  describing  and  justi¬ 

fying  its  actions  and  on-going  requirements 
for  manpower  and  funding. 

A  similar  organization  also  arose,  known  as  the 
"project  office".  Generally,  its  main  distinction  was 
that  this  group  worked  with  less  than  whole  system 
(e.g.,  a  radio  for  use  in  several  aircraft).  Most  of¬ 
ten,  this  project  office  was  directly  controlled  by  an 
intermediary  agency  which  took  the  lead  in  management 
actions  for  all  external  dealings  -  -  especially  for  re¬ 
questing  and  justifying  funds  needed  and  already  spent. 
Currently,  there  are  two  basic  types  of  controlling  ag¬ 
encies,  both  variants  of  the  original  System  Program 
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Office.  One  type  used  a  System  Program  Office  almost 
exclusively  for  the  external  interfaces,  and  emphasizes 
technical  responsibility  in  the  subordinate  project  of¬ 
fice.  The  second  type,  often  called  the  "basket"  System 
Program  Office,  evolved  as  a  natural  consequence  of  the 
functional  shop  organization.  In  this  type,  large  areas 
of  relatively  common  developments  are  grouped  under  one 
composite  System  Program  Office,  which  once  again  handles 
the  external  interfaces.  Whether  one  selects  a  project 
office  or  a  System  Program  Office  to  model  depends  on 
what  requirement  types  are  to  be  investigated. 


A  Requirements  Taxonomy 

Strayer  and  Lockwood  proposed  a  taxonomy  for 
weapon  system  acquisition.  Included  below  are  the  el¬ 
ements  of  that  taxonomy  with  their  description  of  each: 

Mission  Requirements  ultimately  quantify  the  need 
for  acquisition.  Included  in  this  categopr  are  the 
functional  definitions,  e.g.,  transportation  of 
troops,  cargo;  destruction  of  targets;  transmission 
of  messages,  etc..  Also  included  in  this  category 
are  surrogates  for  functions  commonly  called  per¬ 
formance  parameters.  Examples  of  these  are:  speed, 
range,  altitude,  capacity,  effectiveness,  accuracy, 
etc..  In  total,  the  mission  requirements  define  the 
purpose  of  the  system.  They  spell  out  what. the  sys¬ 
tem  is  expected  to  accomplish.  They  deal  with  ac¬ 
complishment  in  the  mission  performance  mode,  that 
is,  in  a  brief,  usually  mission-defined  time  span. 
Thus  they  are  almost  measured  instantaneously  during 
the  test  and  operating  modes.  Measurement,  and 
therefore  evaluation,  can  be  both  rapid  and  reason¬ 
ably  accurate. 


Operating  Characteristic  Heouirements  quantify  many 
of  the  efficiency  indicators  of  the  system.  They 
include  a  much  longer  time  consideration  because 
they  combine  the  functional  components  of  life  cycle 
cost  -  -  reliability,  maintainability,  quantity  and 
quality  operators,  expected  useful  life,  logistics 
support,  and  component  interchangeability  standards. 
These  requirements  impact  on  the  system  design. 
However,  they  are  not  usually  measurable  at  the 
same  time  that  mission  requirements  are  measured. 

The  success  of  satisfying  such  life  cycle  consid¬ 
erations  is  measurable  only  over  time,  frequently 
a  rather  long  time  continuum. 

Design  Standards  and  Specifications  deal  with  the 
transformation  of  mission  requirements  and  oper¬ 
ating  characteristics  into  hardware.  They  describe 
specific  knowledge  of  measurement  inputs  into  the 
design  process.  Included  in  this  category  is  the 
stated  order  of  preference  for  specifications  and 
standards  -  -  components,  materials  and  processes. 
The  order  of  preference  results  from  the  belief 
that  specifications  and  standards  are  the  corporate 
body  of  knowledge.  They  are  codified  lessons 
learned.  As  such,  they  become  inflexible  guide¬ 
lines  or  directives  to  the  contractor.  We  impose 
them  as  design  constraints  in  order  to  avoid  new 
development  costs,  assure  standardization,  strive 
for  competative  procurement  of  homogeneous  products, 
and  avoid  costs  of  nonstandard  components.  All  of 
these  are  worthy  and  desirable  goals. 

Management  Systems  Specifications  and  Standards 
either  specify  the  nature  of  an  organizational  be¬ 
havior  pattern  or  require  the  disclosure  of  specific 
managerial  information.  This  category  is  exampli- 
fied  by  such  things  as  program  management  require¬ 
ments,  system  engineering  management  plans,  reli¬ 
ability  program  plans,  configuration  management 
plans,  cost  schedule  control  systems,  and  the  like. 
The  purpose  of  each  category  in  this  requirement  is 
commons  to  elicit  a  desired  level  of  contractor 
behavioral  or  managerial  response . 

Legal  Obligations  include  both  mandatory  and  bi¬ 
lateral  requirements  that  are  placed  on  the  con¬ 
tractor  and  the  government  program  office  by  basic 
contract  law,  federal  law,  or  agency  regulations. 
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Legal  requirements  are  designed  to  accomplish 
various  national  and  program  management  objec¬ 
tives.  These  have  various  political,  economic, 
technical  or  social  dimensions.  Examples  are  many 
and  include  the  Walsh-Healey  Act,  OSHA,  environ¬ 
mental  protection  regulations,  equal  employment 
opportunity  regulations,  the  cost  accounting  stan¬ 
dards,  and  many  more.  In  addition  to  the  legal 
obligations  mandated  by  law,  bilateral  require¬ 
ments  are  frequently  agreed  on  by  the  contracting 
parties  and  include  type  of  contract,  method  of 
payment,  restitution,  warranties,  correction  of 
deficiencies,  government-furnished  property  or 
services,  forward  pricing  agreements,  adjustment 
for  abnormal  price  escalation,  and  the  like. 

Programming  Requirements  are  allocations  of  total 
program  costs  and  quantities  into  annual  or  other 
periodic  partitions.  These  are  usually  described 
in  terms  of  funding  ceilings,  time-phased  budgets, 
and  delivery  schedules.  In  an  unconstrained  mode, 
these  requirements  are  a  statement  of  when  the 
mission  need  must  be  satisfied.  These  require¬ 
ments  are  initially  defined  by  the  using  command 
and  modified  by  planning  staffs  and  development 
agencies.  Further  modification  or  adjustment  of 
programming  requirements  are  made  throughout  the 
federal  budgetary  process.  The  resolution  of  pro¬ 
gramming  requirements  and  mission  requirements  has 
been  the  focus  of  annual  debate  at  the  national 
level .1 


Two  additions  to  the  Strayer/Lockwood  taxonomy  are  made 
for  the  conceptual  model.  Included  in  the  definition  of 
the  Operating  Characteristic  Requirement  is: 


Operating  Characteristic  Requirements  also  include 
the  functional  statements  that  relate  components > or 
systems  to  some  specific  task  necessary  for  fulfill¬ 
ing  the  mission  requirement.  These  requirements  are 
not  so  broad  as  to  be  mission  requirements,  them¬ 
selves,  but  neither  are  they  as  inflexible  guide¬ 
lines  as  defined  by  design  standards  and  specifica¬ 
tions.  An  example  of  this  type  of  requirement  is 
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the  statement  that  a  radio  must  have  a  back-up 
transmitting  capability  in  case  of  specified  types 
of  failure. 


A  further  addition  to  the  taxonomy  is  the  addition  of  a 
new  type  : 


Interface  Requirements  are  a  special  class  of  op¬ 
erating  characteristic  requirement  which,  by  its 
nature,  deserves  special  attention.  These  express 
a  preconceived  relationship  between  different  mis¬ 
sion  requirements,  operating  characteristic  require¬ 
ments  or  some  combination.  Interface  requirements 
characteristically  work  with  only  one  side  of  an 
interface  and  is  intended  to  constrain  design  on 
the  other  side  to  a  selected  set  of  characteristics . 
They  often  work  with  specified  functions  and  char¬ 
acteristics  on  an  evolving  design  which  is  required 
to  match  an  existing  design  on  the  other  side  of 
an  interface.  As  design  proceeds  to  its  lowest 
level  of  detail,  it  is  normal  to  see  an  increasing 
number  of  requirements  which  relate  one  detail 
requirement  to  another.  This  type  of  statement  is 
a  logical  consequence  of  evolving  both  sides  of  an 
interface  together.  The  lack  of  preconception  on 
one  side  rules  this  out  as  an  interface  requirement 
and  makes  it  simply  a  design  standard  and  speci¬ 
fication  requirement. 

The  conceptual  model  thus  uses  an  expanded  Strayer/ 

Lockwood  taxonomy.  For  ease  of  description,  the  ele¬ 
ment  titles  have  been  shortened: 


Mission  Requirements 
Operational  Characteristics 
Interface  Requirements 
Design  Requirements 
Management  Systems 
Legal  Obligations 
Programming  Requirements 


The  focus  is  further  narrowed,  as  one  might  have  surmised 
from  the  introductory  chapters,  to  technical  require¬ 
ments.  Indeed,  it  is  the  premise  of  the  historical 
evaluation  that  Management  Systems,  Legal  Obligations, 
and  Programming  Requirements  have  received  a  dispropor¬ 
tionate  amount  of  attention  while  the  requirements  which 
directly  define  a  system  have  been  neglected.  The  first 
four  requirement  types  in  the  taxonomy  are  technical  re¬ 
quirements  and  are  the  elements  of  study.  Confining 
requirement  types  to  technical  ones  leads  to  selection 
of  project  shops  instead  of  System  Program  Offices  which 
deal  with  the  entire  taxonomy  of  requirements. 

The  Life  Cycle  Development 

When  considering  the  relationships  of  requirement  types 
over  time,  one  sees  a  close  parallel  in  the  interest  on 
the  life  cycle  of  a  program.  The  product  life  cycle  cf 
a  weapon  system  is  not  described  in  terms  of  require¬ 
ments,  yet  it  also  addresses  development  of  a  product 
from  concept  to  final  product.  Understanding  and  use 
of  the  notion  of  life  cycle  therefore  provides  a  valuable 
touchstone  with  which  to  relate  requirement  growth. 

The  original  cycle  from  a  military  vantage  was 
simply  inspection  and  use.  The  item  was  inspected  or 
tested  to  see  if  it  met  a  set  of  (often  unwritten)  needs. 
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If  it  did,  it  was  purchased  and  put  into  use.  Entry  of 

the  government  into  the  weapon  development  business 
added  that  phase  before  an  item  was  tested  and  used.  As 
weapon  systems  evolved,  requirements  became  mere  complex, 
and  government  involvement  in  early  design  phases  became 
more  intense.  A  phase  for  defining  the  needs  of  the 
program  was  added  to  the  beginning  of  the  program.  Seer, 
from  another  perspective,  the  problem  of  weapon  system 
development  was  rapidly  being  functionally  rationalized. 
The  currently  defined  life  cycle  is: 

1)  .  Conceptual  Phase  -  -  This  phase  is  conducted  at 

the  discretion  of  the  Service  Components  with¬ 
out  specific  approval  of  OSD.  During  this  phase 
the  technical,  military  and  economic  bases  for 
an  acquisition  program  are  established  through 
comprehensive  system  studies  and  experimental 
hardware  development  and  evaluation.  It  in¬ 
cludes  the  early  conception  cf  new  systems  and 
the  program  execution  required  to  provide  the 
technology^  necessary  to  make  the  concept  tech¬ 
nically  feasible. 

2) .  Validation  Phase  -  -  This  is  the  phase  in  which 

the  major  program  characteristics,  through  ex¬ 
tensive  analysis  and  hardware  development,  are 
validated  and  is  often  identified  with  Advanced 
development.  It  is  preferred  that  reliance  be 
placed  on  hardware  development  and  evaluation 
rather  than  paper  studies,  since  this  provides 
a  better  definition  of  program  characteristics, 
higher  confidence  that  risks  have  been  resolved 
or  minimized  and  greater  confidence  in  the  ul¬ 
timate  outcome. 

3) .  Full-Scale  Development  Phase  -  -  During  this 

phase,  the  defense  system  including  all  the 
items  necessary  for  its  support  is  designed,  fa¬ 
bricated  and  tested.  An  essential  activity  of 


the  development  phase  is  test  and  evaluation, 
both  that  conducted  by  the  contractor  and  the 
Service  components. 

4) .  Productive  Phase  -  -  During  this  phase,  the 

defense  system  is  produced  for  operational  use. 

5) .  Deployment  Phase  -  -  During  this  phase  the  de¬ 

fense  system  is  provided  to  and  used  by  oper¬ 
ational  units.  The  Research,  Development,  Test 
and  Evaluation  (RDT&E)  program  structure  used 
in  the  Department  of  Defense  is  predicated  upon 
the  methods  of  budgeting  used  to  fund  certain 
phases  of  the  acquisition.2 

Technical  requirements  of  the  various  types  described  in 
the  expanded  Strayer/Lockwood  taxonomy  (hereafter  simply 
called  the  taxonomy)  flow  through  the  development  part  cf 
the  life  cycle  which  ends  at  the  early  part  of  the  pro¬ 
duction  phase.  The  conceptual  phase  contains  mostly 
Mission  Requirements  and  aggregate  system  Operational 
Characteristics  while  the  other  extreme  of  the  develop¬ 
ment  phase,  the  early  production  period,  contains  the 
greatest  number  of  all  types.  The  general  observation 
that  all  requirement  types  grow  in  number  through  a  tech¬ 
nical  development,  but  that  they  do  so  at  different  rates 
provides  a  starting  framework  to  study  relationships. 


Perspective  on  Growth 

It  can  be  said  that  knowledge  is  derived  by 


fitting  of  observations  to  a  usable  conceptual  frame¬ 
work.  The  first  half  of  the  conceptual  model  is  the 
testing  of  concept  against  observation  for  the  proposed 


elements  cf  the  taxonomy.  This  reduces  to  questioning 
whether  readily  accessible  requirement  documents  reflect 
these  requirement  types  or  not.  Once  it  is  established 
that  elements  can  be  adequately  discriminated,  the 
relational  aspects  become  important.  The  second  half  of 
the  conceptual  model  uses  a  requirements  growth  frame¬ 
work.  Within  that  framework,  it  is  believed  that  some 
requirement  types  show  independent  and  predictable 
trends  beyond  the  most  basic  assumption  of  universal 
growth.  Mission  Requirements  are  thought  to  be  virtually 
independent  of  time.  Design  Requirements  are  considered 
to  start  quite  small  in  number  and  grow  faster  than  any 
other  category.  Operational  Characteristics  and  Inter¬ 
face  Requirements  should  show  grov/th  patterns  between 
these  two  extremes.  Acceptance  cf  this  conceptual  pat¬ 
tern  for  growth  of  the  requirement  types  leads  to  a 
generalization  in  two  parts: 

1) .  existance  of  predictable  patterns  reflects  that 

requirement  growth  conforms  to  order,  and 

2) .  the  proposed  patterns  of  growth  are  a  specific 

form  of  that  order. 

This  second  half  of  the  conceptual  model  is  tested  by 
first  counting  the  number  of  requirements  in  each  cat¬ 
egory  at  a  common  starting  point  in  some  document  com- 


men  to  different  programs.  Subsequent  counts  of  these 
requirements  are  made  for  each  category  in  each  program, 
thus  giving  a  growth  profile.  With  these  data,  the 
first  evaluation  is  of  the  basic  bi-variate  relation¬ 
ships  of  each  category  with  time.  Subsequently,  the 
multi-variate  relationships  among  categories  are  inves¬ 
tigated  . 

Results  of  the  analysis  are  intended  to  lead  to 
support  of  the  proposed  patterns  of  growth  and  thus  cf 
the  general  statement  that  all  requirement  growth  con¬ 
forms  to  order. 
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CHAPTER  FOUR  -  DEFINING  THE  CASE 
AND  PICKING  THE  RESEARCH  SITE 

The  conceptual  model,  built  on  the  historic  and 
academic  background  studies  which  preceded  it,  has  al¬ 
ready  formed  a  basic  outline  of  research: 

1)  .  Air  Force  development  programs  are  used, 

2) .  technical  requirements  defined  in  the  taxonomy 

are  elements  of  the  study, 

3) .  project  offices  in  the  Air  Force  are  the  locus 

of  the  study,  and 

4) .  requirement  type  growth  over  a  project  life 

cycle  is  the  studied  relationship  between  ele¬ 
ments  with  a  specific  growth  pattern  postu¬ 
lated  . 

A  sharpening  of  focus  is  necessary  in  defining  a  case 
rooted  in  concept,  yet  observable  in  existing  data. 
Choosing  the  proper  target  for  a  study  is  an  exercise 
in  "epistemic  correlation".  According  to  adaptation  of 
a  F.  S.  C.  Northrop  idea,  the  conceptual  model  is  de¬ 
scribed  in  terms  of  "concepts  by  postulation"  with  the 
meaning  of  the  conceptual  relationship  expressed  in 
formal  deductive  theory  terms.  Case  data  are  gathered 
in  an  operational  model  which  is  highly  specific  to  the 
specific  target.  This  model  is  therefore  expressed  in 
terms  of  "concepts  by  intuition"  where  "the  complete 
meaning  of  which  is  given  by  something  which  can  be  im- 
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mediately  apprehended".!  A  problem  can  arise  if  the 
specific  operational  model,  while  valid  to  the  particular 
organization  selected,  is  no  longer  reflective  of  the 
more  general  deductive  theory.  The  process  of  insuring 
that  a  model  based  on  "concepts  by  intuition"  properly 
reflects  a  model  based  on  "concepts  by  postulation”  is 
described  as  epistemic  correlation. 

The  following  sections  of  this  chapter  justify 
and  relate  the  selected  study  targets  to  the  concepts 
they  are  supposed  to  mirror. 

Placement  of  the  Study  in  the  Life  Cycle 

The  previously  discussed  phases  of  a  program  life 
cycle  bear  closer  scrutiny.  The  conceptual  phase  is  sub¬ 
ject  to  some  variation  from  project  to  project.  Normally 
however,  the  variation  is  in  the  length  of  time  the  phase 
consumes  rather  than  the  requirement  type  content.  The 
validation  phase  begins  with  the  few  Mission  Requirements 
and  Operational  Characteristics  derived  during  the  con¬ 
ceptual  phase  and  ends  with  almost  the  final  set  of  num¬ 
bers  in  each  requirement  category.  While  these  require¬ 
ments  are  evaluated  and  changed  during  the  full-scale 
development  phase,  the  emphasis  during  this  phase  is  on 
change,  not  growth. 

Because  of  the  time  span  between  concept  and  pro- 
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duction,  and  because  different  Air  Force  groups  in  the 
hierarchy  control  requirements  using  different  documents 
throughout  the  time  span,  it  is  virtually  impossible  to 
find  one  coherent,  yet  common,  set  of  documents  to  cover 
the  whole  life  cycle  for  many  projects.  If  one  had  to 
constrain  his  search  to  documents  in  only  one  phase,  the 
validation  phase  would  appear  to  be  most  appropriate 
since  the  majority  of  program  change  occurs  during  it. 

In  project  offices,  a  common  document  used  dur¬ 
ing  the  validation  phase  is  the  Critical  Item  Specifica¬ 
tion.  Exhibit  One  shows  a  general  format  for  Critical 
Item  Specifications  as  well  as  higher  order  specifica¬ 
tions.  Each  hardware  or  software  component  which  can  be 
individually  identified  (beyond  a  certain  very  low  level) 
has  one  of  these  specifications. 

During  the  early  and  middle  parts  of  the  acquis¬ 
ition  phase,  the  Critical  Item  Specification  is  written 
primarily  in  functional  terms  since  it  reflects  not  act¬ 
ual  hardware  or  prototype  but  only  a  growing  concept  of 
what  the  item  should  be.  This  document  is  called  the 
Part  One  Critical  Item  Specification.  After  a  formally 
designated  review  in  the  concept  development  called  a 
"critical  design  review",  this  document  is  re-drafted 
into  a  more  detailed  description  document  called  a  Part 


Two  Critical  Item  specification.  In  the  case  of  the 
Part  One  specification,  emphasis  is  on  evolution  of  the 
concept!  in  Part  Two  specifications  emphasis  is  on  mak¬ 
ing  the  concept  producable.  The  Part  Two  specification 
builds  on  the  evolution  already  incurred  by  the  Part  One 
specification  since  its  initial  version  reflects  the  eve 
lved  baseline  of  a  string  of  Part  One  revisions.  Use  of 
the  Part  One  is  thus  preferred  over  the  Part  Two  when 
evaluating  requirement  growth  since  use  of  the  latter 
only  obscures  the  great  progress  already  accomplished 
in  the  Part  One . 

Use  of  both  specification  parts  would  be  the 
preferred  research  alternative  but  the  extreme  volume  of 
requirements  in  a  typical  Part  Two  specification  sug¬ 
gests  that  it  not  be  counted  unless  really  necessary  for 
the  research  to  be  meaningful .  The  previous  rationale 
concerning  concept  development  and  producability  attain¬ 
ment  being  the  respective  specification  goals,  argues 
that  the  most  sensitive  specification  to  growth  in  re¬ 
quirements  is  the  Part  One.  This  true  because  of  the 
general  Air  Force  policy  which  makes  weapon  systems  re¬ 
quiring  advanced  manufacturing  techniques  and  materials 
rare.  If  the  hypothesis  concerning  orderly  growth  is 
not  borne  out  by  the  more  change  sensitive  Part  One  spec 
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ification,  then  expansion  to  the  Part  Two  is  not  likely 
to  change  the  results.  Accordingly,  Part  One  specifica¬ 
tions  are  used. 

Selection  of  the  Research  Site 

There  are  three  Air  Force  locations  with  enough 
projects  to  allow  an  adequate  base  of  evaluations  Space 
and  Missile  Systeir.  Organization  in  El  Segundo,  Calif¬ 
ornia;  Electrical  Systems  Division  in  Eoston,  Massachu¬ 
setts',  and  Aeronautical  Systems  Division  in  Dayton,  Ohio. 
While  there  are  differences  in  the  programs  at  the  var¬ 
ious  sites,  all  face  common  problems  of  uncertainty  and 
all  use  essentially  standard  management  systems.  Of  the 
three  sites,  Aeronautical  Systems  Division  was  selected. 
The  Major  reason  for  selection  was  the  large  number  of 
projects.  A  second  reason  was  the  ability  to  gain  access 
to  projects  because  of  the  researcher's  acquaintance  with 
several  of  the  major  program  leaders  and  staff. 

Selection  of  the  Projects 

Earlier,  the  distinction  between  programs  and 
projects  was  made.  Another  general  distinction  even 
among  projects,  is  size.  Smaller  projects  can  be  doc¬ 
umented  with  one  single  Critical  Item  Specification. 

These  projects  avoid  the  complication  of  having  a  hier¬ 
archy  of  specifications  with  extensive  cross-referencing 


between  them.  Requirement  counting  is  especially  dif¬ 
ficult  in  such  a  case  because  one  reference  to  another 
specification  may  actually  reference  a  number  of  require 
ments.  Small  projects  are  therefore  a  prime  target.  An 
other  selection  criterion  used  is  the  avoidance  of  more 
than  one  specification  authored  by  the  same  person.  In 
a  small  sample,  such  as  this  is,  personal  bias  can  be 
significant.  This,  of  course,  should  also  be  true  for 
the  contractor’s  side.  While  they  usually  do  not  write 
the  original  specification,  they  are  generally  most  re¬ 
sponsible  for  the  change  words.  Any  project  evaluated 
for  change  ever  time,  must  have  a  document  reflecting  at 
least  one  revision.  Since  there  are  projects,  mainly 
small  ones,  which  stray  from  the  classical  documentation 
route,  this  becomes  a  concern  and  serves  as  yet  another 
criterion  for  project  selection.  A  project  showing  doc¬ 
uments  with  several  revisions  is  naturally  preferred  to 
one  with  less  changes. 

Major  organizations  in  various  functional  areas 
exist  in  Aeronautical  Systems  Division.  Each  has  an 
array  of  projects  under  it.  Discussions  with  several 
senior  staff  members  prompted  the  conclusion  that  a 

technical  understanding  of  the  work  analyzed  would  be 
highly  beneficial  in  evaluating  possible  specification 

anomolies.  In  many  of  the  highly  specialized  areas  of 
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technical  development,  the  knowledge  of  what  is  atypical 
is  derived  principally  from  specific  experience  in  that 
field.  The  area  of  avionics  was  accordingly  picked  tc 
best  fit  the  researchers  background.  The  term  "avionics" 
attests  to  the  degree  that  technical  complexity  has 
grown.  Although  a  common  term  in  Air  Force  technical 
circles,  it  was  not  included  in  dictionaries  as  late  as 
1966,  and  its  1978  dictionary  definition  carries  the  old 
connotation  of  "avionic  electronics".  The  total  field 
of  aviation  electronics  includes  flight  instrument  elec¬ 
tronics,  special  purpose  weapon  electronics,  and  a  class 
of  electronics  associated  with  navigation,  weapon  deliv¬ 
ery  and  aircraft  active  and  passive  defense  systems. 

This  last  class  of  electronics  is  the  currently  accepted 
definition  of  avionics. 

The  combination  of  all  these  criteria,  serves 
to  limit  the  available  pool  of  projects.  The  major  lim¬ 
it  on  the  number  of  projects,  however,  occurs  on  the  data 
collection  and  analysis  side  of  the  question.  Require¬ 
ment  counting  is  a  lengthy  and,  at  first,  an  iterative 
process.  This  necessitates  a  further  limit  on  the 
number  of  projects  to  a  number  within  the  available 
pool.  The  number  of  seven  projects  was  picked  after  the 
first  iteration  of  requirement  counting  was  completed. 

The  implications  of  using  seven  projects  do  not 
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concern  the  requirements  for  statistical  significance, 
as  one  might  originally  suppose.  As  will  be  shown  in  a 
later  passage,  the  number  of  data  points  taken  for  each 
requirement  type  allows  the  statistical  laws  to  operate 
to  give  a  valid  significance  level.  Rather,  the  problem 
is  basically  one  of  data  homogenity.  Requirement  growth 
patterns  are  considered  to  be  predictable  over  time,  even 
though  different  agencies  work  on  them,  and  consistant 
among  projects,  even  though  different  leaders  are  in¬ 
volved.  Because  of  this,  the  Mission  Requirements  (for 
instance)  of  seven  projects  can  all  be  summed  and  treat¬ 
ed  as  one  sample.  Use  of  a  limited  sample  of  projects 
does  not  test  the  underlying  assumptions  of  homogenity 
rigorously.  A  consistant,  but  unrecognized  bias  in  se¬ 
lecting  projects  for  research  could  conceivably  elimin¬ 
ate  those  projects  evidencing  leadership  or  agency  in¬ 
fluence.  Thus  -a  general  and  broad  claim  concerning  re¬ 
quirement  growth  would  be  supported  by  a  narrow  and  non¬ 
typical  sample.  This  would  be  a  classical  cae  f  im¬ 
proper  epistemic  correlation. 

Project  Versus  Case  Selection 

Once  one  determines  the  number  of  projects  to  be 
evaluated,  he  can  go  two  ways  in  using  the  data.  Data 
collection  procedures  must  be  tailored  to  the  type  of 
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analysis  anticipated  so  the  analysis  method  must  be  con¬ 
sidered  as  an  early  part  of  defining  the  case.  One  way 
to  analyze  the  data  is  to  use  each  project  as  a  case  un¬ 
to  itself.  Possibly,  there  exists  interesting  differen¬ 
ces  between  the  projects  even  if  all  seven  combined  lead 
to  some  common  conclusions.  The  study  would  then  in¬ 
clude  the  differential  contributions  of  each  project  to 
the  common  conclusion,  but  dwell  on  the  reasons  for 
those  differences. 

This  research  starts  with  a  different  premise. 
Its  first  objective  is  to  discover  if  there  are  any  com¬ 
mon  conclusions,  regardless  of  the  differential  inputs. 
The  potential  for  one  project  to  unduly  bias  the  small 
sample  is  not  ignored,  but  study  dwells  only  on  the  ex¬ 
istence  or  absence  of  influence  rather  than  on  root 
causes  of  the  differences.  Accordingly,  the  investiga¬ 
tion  of  undue  project  influence  on  the  sample  is  handled 
by  the  discriminating  methods  of  residual  analysis  and 
plotting  of  outliers. 

Using  this  relaxed  objective  of  only  searching 
for  common  conclusions  has  a  statistical  advantage.  The 
sample  size  can  now  be  based  on  the  aggregate  of  pro¬ 
jects,  rather  than  individual  ones.  One  can  thus  assume 
that  every  observation  of  any  particular  requirement 
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type  is  tied  to  any  other  observation  of  that  type  by 
time  and  not  by  project.  As  an  example:  if  one  were  to 
observe  Mission  Requirements  at  time  zero  on  a  project  by 
project  basis,  he  would  have  seven  cases,  each  with  one 
observation.  If  he  were  to  observe  all  samples  at  time 
zero  (which  incidentally  come  from  seven  projects)  he 
would  have  one  case  with  seven  observations.  The  sample 
size  is  thus  expanded  by  this  expedient.  It  should  be 
noted  that  this  treatment  of  data  does  not  require  one  to 
accept  the  premise  that  there  are  no  differences  between 
projects;  rather,  the  chosen  premise  is  that,  despite 
potential  differences,  there  are  prevailing  tendencies 
common  to  all  projects. 

To  this  point,  the  discussion  has  centered  on 
the  statistical  advantages  of  combining  data  into  an  en¬ 
larged  base  not  possible  when  evaluating  on  a  project 
basis.  These  advantages  come  only  by  leaning  heavily  on 
the  assumption  of  data  homogenitv.  This  is  necessary 
because  even  if  the  results  derived  from  the  supposed 
homogenous  data  does  show  marked  common  tendencies,  it 
does  not  confirm  horoogenity  for  the  general  theory  in¬ 
volving  all  requirements,  unless  the  sample  of  projects 
is  reflective  of  the  whole  population. 

The  three  major  confounding  influences  to  data 
homogenity  are  involvement  by  different  agencies  in  the 
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evolution  of  requirements,  differences  of  product  use 
(such  as  satellite  versus  aircraft),  and  differences  of 
diverse  project  managements  in  the  controlling  of  re¬ 
quirement  growth . 

Although  different  agencies  are  involved  in  a 
development,  their  direct  control  is  virtually  all  in 
the  conceptual  phase  and  their  product  is  mostly  a  list 
of  Mission  Requirements.  The  major  difference  among 
projects  initially  controlled  by  different  agencies  is 
reflected  in  the  different  numbers  of  initial  require¬ 
ments  and  not  in  the  subsequent  growth  process. 

Both  Air  Force  history  and  academic  analysis  con¬ 
firm  that  project  management  is  basically  differentiated 
by  uncertainty  and  complexity  from  other  management  ef¬ 
forts,  and  that  within  this  category,  many  common  prob¬ 
lems  and  solutions  occur  for  a  wide  spectrum  of  products 
and  company  managements.  Within  the  Air  Force,  this 
commonality  has  been  further  reduced  to  a  code  in  man¬ 
uals,  regulations,  and  other  restrictions  and  guides 
generally  applied  across  all  projects.  In  order  to  be¬ 
lieve  that  differences  are  more  prevalent  in  Air  Force 
projects  than  similarities,  one  must  believe  that  Air 
Force  project  leaders  and  workers  grounded  in  common  back 
grounds,  facing  common  environments  of  uncertainty  and 


complexity,  and  complying  with  essentially  common  manag 
ment  and  reporting  requirements  still  wield  overwhelm¬ 
ingly  diverse  impacts  on  the  requirement  growth  process 
A  necessary  premise  for  maintaining  homogenity  is  that 
Air  Force  projects  have  common  tendencies,  net  that  the 
are  identical  relative  to  requirement  growth.  Logic  an 
observation  support  this  premise. 


Orderly  Growth 

The  concept  of  orderly  growth  must  be  stated 
more  directly  in  order  to  be  tested.  Orderly  growth  is 
evidenced  by  linear  relationships  between  independent 
variables  and  time,  and  by  linear  relationships  between 
combinations  of  variables  using  one  of  their  group  as 
the  dependent  variable.  Transformations  are  available, 
if  necessary,  to  accommodate  curvilinear  data. 
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CHAPTER  FIVE  -  RESEARCH  ORGANIZATION  AND  ANAI.YSIJ 


Data  are  produced  by  processing  rav;  information. 
Part  one  Critical  Iter.  Specifications ,  which  contain 
written  requirements!  and  numbers  of  requirements,  by 
type,  are  generated.  This  process  is  done  cr.  each  re¬ 
vision  cf  each  specification,  and  the  time  from  initial 
specification  publication  is  tagged  to  each  observa¬ 
tion.  All  observations  of  an  initial  specification  are 
tagged  with  a  time  zero. 


Use  of  Producible  Data 

The  selection  cf  a  part  one  Critical  Iter.  Spec¬ 
ification  is  relatively  simple,  since  few  other  docu¬ 
ments  are  ccnsistantly  available  among  projects.  Net 
only  is  the  document  available,  but  its  use  carries  a 
requirement  for  a  formalized  system  of  control,  includ¬ 
ing  change  control  and  filing.  The  other  alternative  tc 
Critical  Item  Specifications  is  a  document  called  the 
Statement-of-Work .  This  states  what  work  is  required  of 
the  contractor  in  a  highly  structured  format  which  fol¬ 
lows  closely  the  hardware  component  breakdown.  It  is 
therefore  a  point  by  point  statement  of  the  work  neces¬ 
sary  to  meet  the  technical  requirements.  It  is  an  in¬ 
direct  measure  of  requirements  as  opposed  to  a  Critical 
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Item  Specification's  direct  measure.  Further,  the  State- 
ment-of-Work  is  written  in  general  terms  so  as  to  not 
need  changing  as  technical  details  are  added  to  a  pro¬ 
duct  baseline.  It  is  a  poor  indicator  of  growth. 

Counting  Versus  Sampling 

The  decision  between  counting  or  sampling  re¬ 
quirements  from  the  specifications  is  essentially  one  of 
extending  the  usefulness  of  this  dissertation  beyond  the 
immediate  conclusions.  If  a  sampling  system  can  be  de¬ 
vised  and  shcwr.  to  accurately  reflect  actual  requirement 
counting,  then  other  researchers  need  only  sample  when 
investigating  relationships.  Whether  counting  or  sam¬ 
pling  becomes  the  recommended  procedure,  it  should  be 
recognized  that  counting  is  a  necessary  present  feature. 
The  sampling  system  can  only  be  justified  on  the  basis 
of  its  parallel  results  to  counting. 

Data  Collecting  Procedures 

Data  are  collected  from  the  specifications  using 
a  process  described  in  Appendix  Two.  In  keeping  with 
an  earlier  charge  to  maintain  an  epistemic  correlation 
as  a  bridge  between  concepts  and  observed  data,  the  con¬ 
ceptual  definitions  of  requirement  types  are  modified  to 
reflect  their  typical  appearance  in  Critical  Item  Speci- 
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fications.  These  are  not  changes  which  delete  any  el¬ 
ement  of  the  conceptual  definition,  but  rather  are  ad¬ 
ditions  which  make  the  conceptual  definitions  more  pre- 

i 

cisely  tailored  to  the  document: 

Mission  Requirements  in  Critical  Item  Specifications 
are  often  included  in  the  introductory  paragraphs.  - 

Unlike  the  top  specification  of  an  entire  weapon  sys-  ■ 

tem,  Critical  Item  Specifications  generally  describe  , 

a  product  designed  to  be  used  with  something  else.  j 

Further,  the  product  is  often  a  replacement  for  a  ,] 

previous  obsolete  unit.  Relational  statements  con-  •! 

ceming  other  interfacing  units  are  thus  common  and  j 

Mission  Requirement  statements  of  Critical  Item  Spec¬ 
ifications  are  usually  not  as  complete  and  adequate 
as  those  for  an  entire  weapon  system.  Relational 
statements  must,  in  this  unique  instance,  be  counted 
as  Mission  Requirements. 

Operational  Characteristics  in  Critical  Item  Speci¬ 
fications  initially  describe  the  functions  of  each 
component  in  brief  passages.  Subsequently  the  major 
operational  relationships  between  components  are  de¬ 
scribed  . 

Design  Requirements  in  Critical  Item  Specifications  I 

are  often  specific  and  inflexible  requirements  about 
the  most  critical  performance  features.  They  are  of¬ 
ten  intended  to  put  a  floor  on  performance  at  the  le¬ 
vel  of  current  comparable  units  to  insure  getting  a 
product  which  will  give  comparable  or  better  overall  1 

performance.  Since  one  detailed  Design  Requirement 
often  directly  constrains  interfacing  components,  it 
is  not  unusual  to  see  clusters  of  Design  Requirements 
around  a  particular  required  performance  capability. 

Interface  Requirements  in  Critical  Item  Specifications 
are  usually  first  seen  as  a  functional  interface  dia¬ 
gram.  Interface  Requirements  in  the  rest  of  the  spec¬ 
ification  seem  to  exhibit  no  pattern  of  early  or  late 
inclusion. 


MMiUttttMMIM 


The  conceptual  model  has  two  parts.  The  first 


part,  comprising  the  elements  of  the  study,  is  the  in¬ 
vestigation  of  the  taxonomy  to  see  if  the  conceptual 
elements  can  be  identified  and  counted  in  specification 
The  second  part  is  the  relationship  assumed  between 
these  elements,  that  of  orderly  growth.  Research  of 
the  data  taken  from  specification  requirement  counting 
parallels  the  conceptual  model  with  an  analysis  of  the 
requirement  counting  process  coming  first,  followed  by 
linear  regression  analysis  of  element  relationships. 

The  basic  organization  of  the  requirement  counting 
process  is  given  in  Appendix  Twa 

The  Regressions 

The  regression  analyses  use  The  University  of 
Texas  at  Austin's  computerized  version  of  "The  Stat¬ 
istical  Package  for  the  Social  Sciences,  second  edi¬ 
tion."1  The  specific  relationships  investigated  are: 

1) .  Mission  Requirements  with  time; 

2) .  Operational  Characteristics  with  time; 

3) .  Interface  Requirements  with  time; 

4) .  Design  Requirements  with  time; 
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5)  •  Mission  Requirements  with  Operational  Charac¬ 

teristics,  Interface  Requirements,  and  Design 
Requirements ; 

6)  .  Operational  Characteristics  with  Mission, 

Interface,  and  Design  Requirements; 

7) .  Interface  Requirements  with  Mission  Require¬ 

ments,  Operational  Characteristics  and  Design 
Requirements;  and 

8) .  Design  Requirements  with  Mission  Requirements, 

Operational  Characteristics  and  Interface  Re¬ 
quirements  . 

Positive  relationships  of  each  requirement  type  with 
time  are  the  simplest  expression  of  orderly  growth  and 
therefore  are  important.  Mission  Requirements  should 
show  virtually  no  growth  at  all,  with  Operational  Char¬ 
acteristics  through  Design  Requirements  showing  increas¬ 
ingly  steep  slopes. 

The  multivariate  relationship  can  provide  the 
accuracy  of  prediction  not  available  in  simpler  bi¬ 
variate  equations.  Analysis  of  the  multiple  relation¬ 
ships,  especially  the  residual  analyses  and  the  variance/ 
covariance  matrices  can  give  major  insights  to  the  pat¬ 
terns  of  growth  and  especially  the  effects  of  multi - 
collinearity . 

The  projects  which  provide  the  data  are  listed 
in  Appendix  Four.  The  raw  data  input  to  the  linear  reg¬ 
ressions  are  shown  in  Table  One.  Organization  of  that 


* 
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TABLE  ONE 


REQUIREMENT  TYPES  -  RAW  COUNT  OF  2' 


TIME 

MISREQ 

OPCHAR 

DERSS 

INTSRFAC 

0 

11 

61 

143 

18 

0 

8 

69 

364 

26 

0 

9 

117 

531 

120 

0 

3 

16 

275 

62 

0 

11 

63 

286 

39 

0 

6 

229 

149 

62 

0 

8 

121 

94 

43 

4 

8 

127 

101 

4  5 

5 

8 

150 

133 

56 

5 

11 

65 

302 

40 

7 

6 

341 

340 

81 

13 

7 

360 

632 

104 

14 

9 

85 

603 

37 

15 

11 

86 

252 

32 

15 

9 

120 

585 

123 

16 

11 

71 

336 

47 

17 

8 

176 

145 

68 

21 

3 

19 

292 

79 

22 

8 

238 

192 

89 

29 

11 

75 

422 

47 

3^ 

4 

11 

31 

76 

335 

438 

93 

48 

51 

4 

44 

427 

120 

NOTE:  The  following  acronyms  are  used  throughout  the 
tables  in  this  dissertation: 

MISREQ  -  -  MISSION  REQUIREMENTS 

OPCHAR  -  -  OPERATIONAL  CHARACTERISTICS 

DERSS  -  -  DESIGN  REQUIREMENTS 

INTERFACE  -  -  INTERFACE  REQUIREMENTS 
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data  is  chronological  by  months.  All  data  relationships 
are  presented  without  missing  data.  Thus  correlation 
of  any  two  requirement  types  such  as  Mission  Require¬ 
ments  and  time  is  made  using  pairs  corresponding  to  the 
number  of  data  "points"  or  observations.  Twenty-three 
data  points  in  the  computer  run  translate  to  twenty- 
three  pairs  of  Mission  Requirement  and  time.  The  re¬ 
sults  of  running  the  raw  data  in  the  linear  regressions 
is  shown  in  Appendix  Five  .  Table  Two  gives  some  of  the 
selected  results.  When  evaluating  the  results  shown  in 
Table  Two,  the  single  most  striking  observation  is  the 
smallness  of  the  bivariate  correlations  of  each  require¬ 
ment  type  with  time.  When  the  projects  were  plotted  in¬ 
dividually,  the  requirement  types  exhibited  a  stronger 
correlation  with  time  than  the  aggregate  data  indicated. 

Transformation 

After  reflection,  it  seemed  that  when  each  pro¬ 
ject's  contribution  was  compared  with  other  projects, 
the  very  large  differences  in  the  initial  numbers  of 
requirements  in  each  category  swamped  the  regression 
and  obscured  the  trend.  In  two  requirement  types,  the 
differences  in  total  initial  numbers  approached  one  or¬ 
der  of  magnitude.  It  is  probable  that  if  each  project 
had  started  with  a  common  base  number  at  time  zero, 


TABLE  TWO 


SELECTED  COMPUTER  RESULTS  -  23  RAW  DATA  POINTS 
BIVARIATE  CORRELATION  COEFFICIENTS 


OPCHAR 

-  .02328 

DERSS 

.06743 

.00954 

INTERFACE 

-.49910 

.30396 

. 44^41 

TIME 

-.18808 

-.17663 

•33^21 

.39799 

MISREQ 

OPCHAR 

DERSS 

INTERFACE 

MULTIVARIATE  RELATIONSHIP  OF  MISSION  REQUIREMENTS 
MISREQ  =  -.6274  INTERFACE  +  .6401  DERSS  +  .60?4  OPCHAR 
+  9.  3317 
F  SCORE  =  .023 
R  SQUARE  =  .3873 


'% 

1 

i 
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the  resulting  growth  would  have  been  closer  to  the  in¬ 
tuitive  results  seen  in  the  project  plot.  A  transfor¬ 
mation  was  done  on  the  data.  Each  observation  in  every 
requirement  type  category  was  divided  by  the  initial  re¬ 
quirement  number  in  that  category  thus  making  the  trans¬ 
formed  data  a  rate  of  growth  figure  on  the  base  one.  It 
was  recognized  that  this  made  the  measurement  a  ratio 
which  carries  its  own  special  burden  in  statistical  an¬ 
alysis,  but  it  was  felt  that  these  potential  problems 
could  be  dealt  with  effectively.  Table  Three  shows 
this  transformed  data.  The  resultant  computer  run  is 
given  in  Appendix  Six .  Selected  results  from  that  run 
are  shown  in  Table  Four. 

Sample  Size 

Previous  considerations  of  sample  size  concern¬ 
ed  the  goals  of  the  research  and  led  to  an  increased 
size  from  the  original  base  because  of  the  understand¬ 
ing  that  aggregate  conclusions  rather  than  differences 
between  projects  were  desired.  The  first  two  data  runs 
occasioned  a  second  opportunity  to  consider  the  way  data 
are  fitted.  When  the  common  denominator  for  data  ob¬ 
servation  shifted  from  the  project  to  time  no  consid¬ 
eration  was  given  to  whether  the  original  data  collec¬ 
tion  methods  were  still  appropriate .  Had  the  research 


TABLE  THREE 

TRANSFORMED  DATA  -  -  COUNT  OF  23 


TIME 

MISREQ 

OPCHAR 

DERSS 

INTERFACE 

0 

1  .00 

1 .00 

1.00 

1.00 

0 

1.00 

1.00 

1 .00 

1.00 

0 

1.00 

1.00 

1.00 

1.00 

0 

1.00 

1.00 

l.OC 

1.00 

0 

1.00 

1 .00 

1.00 

1.00 

0 

1.00 

l.OC 

1.00 

1.00 

0 

1.00 

1.00 

1.00 

1.00 

4 

1.00 

1.05 

1.07 

1.05 

5 

1.00 

1.24 

1 .32 

1.32 

5 

1  .00 

1 .03 

1.06 

1.03 

7 

1.00 

1.50  ‘ 

2.28 

1.31 

13 

1.17 

1.57 

4.24 

1.68 

14 

1.11 

I.23 

1.66 

1 .42 

15 

l.OC 

1.41 

1.76 

1.78 

15 

1.00 

1.03 

1.10 

1.03 

16 

1.00 

1.13 

1.17 

1.05 

17 

1 .00 

1.45 

1.48 

1.58 

21 

1.00 

1.19 

1.06 

1.27 

22 

1.00 

1.72 

1.90 

2.07 

29 

1.00 

1.19 

1.48 

1 .26 

32 

1.33 

1.92 

1.22 

1.50 

34 

1.00 

1.21 

1-53 

1.23 

51 

1.33 

2.75 

1.55 

1.93 

TABLE  FOUR 


SELECTED  COMPUTER  RESULTS  -  23  TRANSFORMED  DATA  POINTS 
BIVARIATE  CORRELATION  COEFFICIENTS 


OPCHAR 

•78996 

DERSS 

•33339 

.36964 

INTERFACE 

.50680 

.85118 

.58529 

TIME 

.6273^ 

.79290 

.24143 

.65375 

MISREQ 

OPCHAR 

DERSS 

INTERFACE 

MULTIVARIATE  RELATIONSHIP  OF  MISSION  REQUIREMENTS 

MISREQ  =  .3^36  OPCHAR  -  .2839  INTERFACE  +  .50081  DERSS 
+  89.371 

F  SCORE  =  0 

R  SQUARE  =  .79329 
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been  done  originally  on  a  time  basis,  it  would  have  re¬ 
quired  that  for  every  pre-set  point  in  time,  data  be 
taken  across  the  spectrum  of  requirement  types  for  each 
project.  Thus,  if  project  A  was  the  only  project  to 
change  at  time  X,  all  other  projects  would  still  have  to 
be  counted  at  time  X,  even  though  unchanged.  This  led  to 
an  array  of  data  as  seen  in  Table  Five.  The  resultant 
computer  run  is  shown  in  Appendix  Seven.  As  in  the  pre¬ 
vious  case,  selected  results  are  incorporated  in  this 
section  in  Table  Six. 

Evolution  of  the  Final  Model 

When  the  transformed  and  expanded  data  base  is 
analyzed,  the  results  are  markedly  different  from  the 
raw  data  runs  originally  tried.  While  simple  bivariate 
relationships  with  time  are  still  not  high,  they  have 
now  increased  to  better  than  .5  in  three  out  of  four 
cases.  The  significances  of  all  relationships  is  quite 
high,  indicating  a  good  fit  of  the  data  to  the  resultant 
equations.  R  square  for  the  multivariate  relationships 
are  better  than  .8  for  all  except  Design  Requirements 
which  is  .61.  The  residuals  of  Y  estimated  values  versus 
Y  observed  values  for  the  multivariate  equation  describ¬ 
ing  Mission  Requirements  show  five  outliers  which  involve 
7.81  percentum  of  the  total  number  of  points  sampled. 


AD-A107  875  AIR  FORCE  INST  OF  TECH  VRI6HT-PATTERS0N  AFB  OH  F/6  5/i 

A  STUDY  OF  RESEARCH  AND  DEVELOPMENT  CONTRACT  REQUIREMENTS  AND  T— ETC (U) 
MAY  79  R  6  0LACKLEO6E 

UNCLASSIFIED  AFIT-CI-79-2J4D  NL 
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TABLE  SIX 

SELECTED  COMPUTER  RESULTS  -  64  TRANSFORMED  DATA  POINTS 
BIVARIATE  CORRELATION  COEFFICIENTS 


OPCHAR 

.79928 

DERSS 

.40676 

.45452 

INTERFACE 

.54741 

. 87447 

.64128 

TIME 

.52805 

.66998 

.16147  .52342 

MISREQ 

OPCHAR 

DERSS  INTERFACE 

MULTIVARIATE  RELATIONSHIP  OF  MISSION  REQUIREMENTS 
MISREQ  =  .3811  OPCHAR  -  .3056  INTERFACE  +  .4824  DERSS 
+  .87421 
F  SCORE  =  0 
R  SQUARE  =  .81078 


Three  of  these  outliers  are  from  the  same  program.  On  a 
subsequent  trip  to  Wright-Patterson  Air  Force  Base,  this 
project  was  again  examined.  A  change  in  the  basic  mis¬ 
sion  of  this  critical  item  had  occurred  subsequent  to 
the  first  submission  of  the  Fart  One  specification. 

This  fact  had  been  known  early  in  the  research  but  a 
decision  was  made  to  leave  it  in.  The  change  had  been 
directed  early  in  the  project  and,  given  the  fact  that 
the  project  was  a  long  one,  it  was  thought  that  the  sev¬ 
eral  specification  revisions  would  allow  a  graceful 
accommodation  of  the  various  requirement  types  to  the 
new  direction,  but  this  did  not  happen.  Accordingly, 
data  from  this  particular  case  were  dropped  from  further 
consideration.  The  sample  size  dropped  from  sixty-four 
to  sixty. 

A  computer  program  was  now  run  with  the  sixty 
remaining  data  observations,  but  with  raw  data  (see 
Appendix  Eight) .  This  was  done  to  check  the  model  sen¬ 
sitivity  to  the  extreme  data.  The  original  rationale 
for  transformation  did  not  consider  the  possibility 
of  isolated  erroneous  data  acting  as  a  strong  force 
because  of  the  small  number  of  projects  involved.  Its 
conclusion,  in  fact,  was  that  patently  valid  data,  be¬ 
ginning  from  greatly  different  initial  bases,  had  the 
common  trends  obscured.  If  removal  of  one  anomolous  set 


of  observations  significantly  changed  the  raw  data  cor¬ 
relations,  even  if  the  results  were  not  as  good  as  the 
transformed  data,  then  a  major  blow  would  have  been 
struck  to  the  rationale  for  transformation.  The  results 
of  the  second  raw  data  run  were  similar  to  the  first 
raw  data  run  with  very  low  correlations  with  time  and 
generally  poorer  statistical  significances  than  trans¬ 
formed  data  as  shown  by  the  F  scores.  When  the  trans¬ 
formed  data  were  run  with  the  extreme  data  removed,  only 
two  outliers  were  found.  This  program  was  used  for  the 
major  findings.  The  program  is  located  in  Appendix 
Nine  and  is  discussed  in  the  chapter  on  research  find¬ 
ings. 

The  statistical  techniques  used  in  the  multi¬ 
variate  analyses  is  principally  analysis  of  variance 
using  the  computer's  ANOVA  routine.  The  ANOVA  routine  is 
basically  an  analysis  of  variance  technique  adapted  for 
computers.  It  is  based  on  partitioning  of  the  variations 
of  sums  of  squares  of  data  conforming  to  factorial  de¬ 
sign.  Linear  regressions  are  investigated  using  this 
technique  by  noting  the  sum  of  squares  of  the  residuals 
to  that  of  the  total  regression.  These  values,  adjusted 
for  each  figure's  calculated  degrees  of  freedom,  are  com¬ 
pared  in  an  "F"  ratio.  The  significance  figure  derived 
from  tabulated  F  ratios  gives  the  probability  that  a 


null  hypothesis  exists  that  there  is  no  linear  relation¬ 
ship  of  the  tested  data.  This  technique  is  used  for 
regression  equations  and  for  individual  coefficients  in 
the  equations.  Immediately  below  the  F  ratio  analyses 
of  a  given  relationship  (as  shown  in  the  ANOVA  computer 
print-out),  the  prediction  equation  is  derived  for  the 
dependent  variable.  This,  coupled  with  an  earlier  print¬ 
out  of  R  square  and  standard  deviation  of  the  regression 
line  defines  the  relationship.  Several  major  options, 
including  plotting  of  residuals,  analysis  of  those  data 
using  Von  Neumann  and  Durbin-Watson  tests,  correlation 
coefficient  tables,  and  variance/covariance  matrices  are 
also  offered  by  the  ANOVA  routine. 

Step-wise  inclusion  of  the  independent  variables 
into  the  model  is  used  because  this  is  the  most  general 
test  and  it  allows  insight  into  the  dominant  independent 
requirement  type  in  predicting  a  dependent  requirement 
type  variable.  This  decision  is  even  more  appropriate 
when  combined  with  the  second  decision  to  not  specify 
a  tolerance  level  for  inclusion  of  independent  variables 
into  the  model.  All  variables  are  ultimately  input  to 
the  model. 

Multicollinearity  Investigations 

It  is  reasonable  to  hold  a  starting  assumption 


that  certain  requirements,  such  as  Mission  Requirements, 


90 


might  directly  influence  the  numbers  of  other  requirement 
types.  The  bulk  of  the  earliest  requirements  (seen  in 
the  early  conceptual  stage)  are  Mission  Requirements, 
Further,  the  accepted  practice  of  establishing  precedence 
among  specifications  and  among  paragraphs  in  specifica¬ 
tions,  has  been  observed  to  attach  importance  to  Mission 
Requirements  out  of  proportion  to  their  number.  Taking 
two  observations  made  about  Mission  Requirements  to  a 
level  of  abstraction,  one  could  say  that  requirements 
that  are  established  first  in  a  chronological  sequence 
and  which  are  also  deemed  most  important  in  case  of  re¬ 
quirement  conflict,  are  most  likely  to  force  growth  in 
requirements  which  come  and  are  less  important.  Mission 
Requirements  fit  the  "early"  and  "important"  criteria 
and  thus  might  force  requirement  growth  in  other  require¬ 
ment  types.  It  can  be  seen  that  any  argument  that  in¬ 
volves  time,  importance  and  requirement  type,  as  they 
relate  to  requirement  growth,  is  tenuous  because  it  im¬ 
plies  a  cause  and  effect  relationship  based  solely  on  a 
closed  system  of  requirement  types.  This  was  a  major 
consideration  in  not  specifying  a  method  other  than  step¬ 
wise  inclusion  for  insertion  of  independent  variables 
into  regressions.  The  potential  relationships  can¬ 
not  be  ignored  when  investigating  multicollinearity , 
however.  Both  the  bivariate  statistics  and  the  variance/ 
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covariance  matrices  give  insight  to  this  problem.  Under 
the  closed  system,  Mission  Requirement  causal  theory, 
one  should  see  the  strongest  multicollinearity  rela¬ 
tionships  cascade  down  from  Mission  Requirements  to 
Operational  Characteristics  to  Interface  Requirements  to 
Design  Requirements.  A  healthy  multicollinearity  be¬ 
tween  them  all  should  therefore  be  found.  A  result 
showing  orderly  growth  of  the  requirement  types  without 
multicollinearity  does  not  hurt  the  orderly  growth  ar¬ 
gument  but  it  destroys  the  posited  closed  system.  A 
complicating  relationship  to  this  analysis  is  that  of 
Interface  Requirements  to  Operational  Characteristics. 
Strayer  and  Lockwood  did  not  see  enough  difference  in 
these  two  categories  to  separate  them  in  their  original 
taxonomy.  If  they  are  right,  multicollinearity  between 
these  two  categories  should  be  extremely  high.  Multi¬ 
collinearity  plays  such  a  big  role  in  the  conclusions  cf 
this  research,  that  further  discussion  is  held  for  the 
chapter  findings. 

Autocorrelation  Investigations 

Time  series  classically  contain  some  or  all  of 
four  types  of  movement.  One  author  defines  these  as 
secular  trend,  periodic  variation,  cyclical  movement, 
and  irregular  fluctuations.^  The  key  to  how  one  views 
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a  time  series  is  directly  tied  to  his  primary  interest. 

In  business i  the  secular  trend  is  very  often  a  simple 
reflection  of  population  growth.  Beyond  this  are  the 
periodic  variations  such  as  seasonal  influences.  Often, 
when  one  controls  for  these  two  influences,  he  can  see, 
for  a  given  industry,  that  it  runs  in  cycles.  A  busi¬ 
nessman  may  wish  to  know  where  he  is  in  a  cycle  or  he 
might  want  to  know  what  to  expect  from  the  Christmas 
rush.  Depending  on  what  he  wants  to  know,  he  will  con¬ 
trol  or  suppress  certain  effect. 

This  analysis  starts  with  a  different  focus. 

The  aim  is  not  to  control  the  regression  for  some  known 
trend  in  order  to  isolate  independent  effects,  but  rather 
to  determine  if  the  data  indicates  some  secular,  but 
unknown  trend  at  work.  The  original  belief  concerning 
what  caused  order  to  be  established  in  a  system,  was 
that  certain  forces  like  uncertainty,  size,  cost,  and 
complexity  set  an  initial  burden  on  a  development.  The 
system  responded  in  an  orderly  manner  with  Mission  Re¬ 
quirements  leading  the  process.  If  these  external  forces 
do  not  just  set  the  initial  conditions,  but  continue  to 
act  throughout  the  development,  they  will  be  seen  as 
secular  trends  and  will  probably  emerge  in  tests  for 
autocorrelation . 


Autocorrelation  is  checked  using  the  Durb in- 
Watson  Test  and  the  more  sensitive  Von  Neumann  Ratio. 
Further,  the  effects  of  entering  time  as  an  independent 
variable  is  indicative  and  is  investigated  (see  Appendix 
Ten  ) .  The  results  do  not  support  findings  of  any  sig¬ 
nificant  autocorrelation  in  the  data.  The  Durbin-Watscr. 
Tests  and  Von  Neumann  Ratios  are  generally  negative  with 
the  only  exceptions  showing  mixed  results  between  the 
two  tests  in  two  cases.  The  inclusion  of  time  as  an 
independent  variable  improves  correlations  only  at  the 
fourth  decimal,  leading  to  the  conclusion  that  any  time 
based  trend  is  not  significant.  These  findings  are  net 
surprising,  when  considering  the  classical  way  a  program 
is  defined  relative  to  these  potential  secular  forces. 
While  the  state  of  the  art  of  technical  development  in¬ 
creases  with  time,  the  effect  on  a  program  is  minimized 
by  tight  control.  Virtually  all  programs  are  required 
to.  assess  their  technical  risk  early  in  the  development, 
and  those  with  high  risk  are  usually  redefined.  Devel¬ 
opment  programs  which  push  the  state  of  the  art  are 
universally  discouraged.  A  program  starts  with  a  certai 
(although  sometimes  unknown)  degree  of  uncertainty,  com¬ 
plexity  and  size.  It  generally  proceeds  to  certainty. 
Changes  involving  obvious  increases  in  complexity  are 
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discouraged.  Increases  in  size  of  the  product,  or  the 
program  are  discouraged,  although  they  do  happen.  It 
is  logical  to  assume  that  control  over  these  forces  is 
better  on  the  smaller  and  simpler  projects  ar.d  that  is 
what  the  data  support. 
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CHAPTER  FIVE  ENDNOTES 


1.  See  Nie,  Hull,  Jenkins,  Steinbrenner,  and  Bent's 
book  Statistical  Package  for  the  Social  Sciences 
(Bibliography  number  37) • 

2.  Reference  Croxton,  Cowden  and  Klein's  book  Applied 
General  Statistics ,  page  214  (Bibliography  number  ?) . 
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CHAPTER  SIX  -  -  RESEARCH  FINDINGS 
Ability  to  Isolate  Requirements  in  the  Taxonomy 

The  proposed  taxonomy  is  used,  not  to  be  norma¬ 
tive,  but  rather  because  it  reflects  the  natural  order 
of  things  relative  to  requirement  definition.  To  this 
extent,  one  would  expect  to  see  an  extensive  number  of 
easily  recognized  classical  types  for  each  taxonomy  cat¬ 
egory.  This  observation  was  borne  cut  by  the  study. 

Even  among  individual  members  of  one  type  of  document, 
however,  (part  one  Critical  Item  Specifications  for 
avionic  units)  it  is  apparent  that  there  is  an  almost 
endless  number  of  ways  to  compile  requirements  which 
defy  their  isolation  to  some  conceptually  pre-conceived 
taxonomy.  The  fact  that  there  is  no  current  Air  Force 
requirement  definition  system  testifies  to  the  license 
available  to  specification  writers  to  define  requirements 
any  way  they  wish.  The  principle  normative  influence 
on  specification  writers  has  been  past  experience  and 
especially  that  in  their  own  functional  areas.  These 
specifications  are  normally  organized  first  by  a  com¬ 
ponent  breakdown  of  the  critical  item  and  then  by  a 
fairly  standardized  set  of  additional  considerations. 

The  guiding  influence  seen  in  current  writing  of 


requirements  appears  to  be  (beyond  clear  statement  of  the 
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idea  at  hand)  good  transition  and  integration  with  the 
requirements  of  other  paragraphs.  The  general  mechar.i 
characteristics  of  a  piece  of  hardware  appears  tc  have 
bearing  as  well.  A  piece  of  hardware  can  character¬ 
istically  be  broken  down  into  clusters  of  functionally 
oriented  components  which  break  down  into  smaller  and 
smaller  units.  At  the  functional  cluster  level  there 
are  cross -functional  interfaces.  Within  the  clusters 
there  are  intrafaces  between  units  and  interfaces  with 
units  of  other  clusters.  Thus  a  very'  simplistic  view 
cf  a  technical  description  would  show  that  there  are 
functional  cross-sections  at  every'  level  cf  hardware 
component  breakdown; .  It  is  therefore  not  surprising 
that  there  are  numerous  requirement  statements  which 
dc  not  fit  the  taxonomy  cleanly.  The  distinction,  how¬ 
ever,  does  not  seem  to  be  that  there  are  better  theo¬ 
retical  categories  possible,  but  rather  that  there  is 
such  overlap  between  the  postulated  types. 

If  one  assumes  that  there  are  significant  popu 
lations  of  requirement  statements  clustering  around 
each  conceptual  requirement  type,  and  that  all  other 
requirement  statements  are  on  a  continuum  between  any 
given  two  requirement  types,  the  problem  becomes  one  o 
limits  and  sensitivity.  Limits  are  necessary  to  arbi¬ 
trarily  resolve  at  least  some  of  the  grey  areas  back 


effort  t:  arrive  at  the  total  nur.be r  of  requirements 
(both  classical  fits  and  grey  ones)  on  the  initial  pro¬ 
gram  seen.  One  must  assume  some  form,  of  learning  would 
take  place  in  requirement  counting  which  would  make  a 
later  count  of  a  specification’s  requirements  different 
from  the  first  one.  Table  Eight  shows  the  results  of 
three  sequential  counts  on  the  initial  project,  As 
can  be  seen,  the  second  and  third  measures  are  substan- 
tually  closer  than  the  first  and  second.  It  is  recog¬ 
nized  that  this  argument  suffers  the  same  weakness  as 
attributed  to  a  Delphi  process,  namely  that  convergence 
of  subsequent  findings  does  not  necessarily  support  any 


TABLE  SEVEN' 

EVALUATION  OF  REQUIREMENT  TYPES  WHICH  PIT 
CLASSICAL  DEFINITIONS  IN  ONE  PROJECT 


TOTAL  NUMBER 

11 

63 

286 

39 

NUMBER  OF  FITS 

9 

3? 

214 

24 

PERCENTAGE 

.82 

•  59 

.75 

.62 

MISREO 

OPCHAR 

DERSS 

INTERFAC 

100 


TABLE  EIGHT 

REQUIREMENT  COUNTING  LEARNING  CURVE  RESULTS 


MEASURE 

ONE 

11 

48 

226 

46 

MEASURE 

TWO 

11 

60 

271 

39 

MEASURE 

THREE 

:  11 

63 

286 

39 

MISREQ 

OFCHAR 

DERSS 

INTERFAC 
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conclusion  about  the  appropriateness  of  the  mean  con¬ 
verged  upon. 

Basic  Regression  Relationships 

The  basic  equations  for  both  bivariate  and 
multivariate  relationships  are  listed  in  Table  Nine. 
Listed  along  with  the  equations  are  relevant  statistical 
results. 

The  bivariate  relationships  show  little  direct 
correlation  with  time.  High  correlations  are  found  be¬ 
tween  Operational  Characteristics  and  Interface  Re¬ 
quirements  (R  =  .95727)  and  between  Mission  Requirements 
(R  =  .86721)  . 

The  multivariate  relationships  are  uniformly 
high.  Mission  Requirements  are  determined  from  the 
other  requirement  types  with  an  R  square  of  .86689. 

The  significance,  as  given  by  the  F  test,  is  better  than 
.0001.  Individual  coefficients  passed  the  T  test  for 
significance .  Both  the  Von  Neumann  and  Durbin-Watson 
tests  indicate  no  auto-correlation. 

The  operational  Characteristics  are  determined 
with  an  R  square  of  .95920  and  enjoy  the  same  statis¬ 
tical  support  except  for  a  Von  Neumann  Ratio  of  1.78642 
which  indicates  possible  autocorrelation.  The  Durbin- 
Watson  test  is  contra-indicative,  however. 


I* 
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TABLE  NINE 

SELECTED  COMPUTER  RUNS  -  BASIC  EQUATIONS 
AND  STATISTICAL  RESULTS 

COMPUTER  RUN  WITH  ALL  TAXONOMY  ELEMENTS  (APPENDIX  EIGHT) 
Correlation  Coefficients 


OPCHAR  .47420 
DERSS  .86721 
INTERFACE  .45174 
TIME  .01438 


.76490 

.95727  .69115 

.34225  .14226  .34604 


MISREQ 


OPCHAR  DERSS  INTERFACE 


Multivariate  Relationships 
Mission  Requirements 

MISREQ=.069  DERSS-. 206  OPCHAR+.856  INTERFACE+1 .052 

R  square= . 86689 

F=121.56  Significance^ 

Standard  Deviation= .01257 


Opererational  Characteristics 

OPCHAR=.5^2  INTERFACE=.l 56  DERSS-1.721  MISREQ=2.035 

R  square= .95920 

F=438.86  Significance^ 

Standard  Deviations .03635 

Design  Requirements 

DERSS=11 . 860  MISREQ+3.191  OPCHAR-l.237  INTERFACE-12.8 

R  squares. 93220 

F=256 . 66  Significance=0 

Standard  Deviations .16425 

Interface  Requirements 

INTERFACE=1.568  OPCHAR-. 175  DERSS+2.069  MISREQ-2.472 

R  squares .93^52 

F=266.4l  Significance=0 

Standard  Deviations .06184 
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TABLE  NINE 
(  Continued  ) 

COMPUTER  RUN  WITH  INTERFACE  REQUIREMENTS 
AND  OPERATIONAL  CHARACTERISTICS  COMBINED 
(APPENDIX  TEN) 

Correlation  Coefficients 

DERSS  .86721 

OPINT  .46223  .73030 

TIME  .01438  .14226  .34808 

MISREQ  DERSS  OPINT 


Multivariate  Relationships 

Mission  Requirements 

MISREQ  =  .062  DERSS  -  .030  OPINT  +  .99? 

R  square  =  .81189 
F  =  123.0  Significance  =  0 

Standard  Deviation  =  .01428 

Operational/interface  Characteristics 

OPINT  =  .870  DERSS  -  8.158  MISREQ  +  9-390 

R  square  =  .88780 
F  =  51-997  Significance  =  0 

Standard  Deviation  =  .2^607 

Design  Requirements 

DERSS  =  12.317  MISREQ  +  .630  OPINT  -  12.576 

R  square  =  .88780 
F  =  225.58  Significance  =  0 

Standard  Deviation  =  .20940 

NOTE.*  The  combined  variable  Operational/ 
Interface  characteristics  is  repre¬ 
sented  by  the  acronym,  OPINT 
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Design  Requirements  are  determined  with  an  R 
square  of  .93320.  Here,  again,  the  main  disturbance  ir. 
the  supporting  statistics  is  a  mixed  autocorrelation 
test. 

Interface  Requirements  show  an  R  square  of 
.93^52  and  a  good  autocorrelation  test  with  a  Van  Neu¬ 
mann  Ratio  of  2.00295  (2.0000  being  the  expected  value). 

Particular  Relationships  of  Interest 

The  first  area  of  particular  interest  is  that  of 
the  high  bivariate  correlations.  These  are  the  first  in¬ 
dication  of  multicollinearity .  Beyond  giving  valuable 
insight  on  the  requirement  type  relationships,  this 
finding's  primary  importance  lies  in  its  capacity  to 
potentially  confound  meaningful  use  of  the  multivariate 
relationships.  The  high  correlation  between  Operational 
Characteristics  and  Interface  Requirements  (R=. 95727) 
is  simply  explained  and  corrected.  Strayer  and  Lock¬ 
wood's  original  taxonomy  which  made  no  distinction  of  . 
Interface  Requirements  from  Operational  Characteristics 
is  supported  by  this  finding.  Further  Support  is  found 
when  one  analyzes  the  variance/covariance  matrix  for  one 
of  the  multivariate  regressions  involving  these  cate¬ 
gories  as  independent  variables.  Table  Ten  shows  such 
a  matrix  for  the  dependent  variable  Mission  Require- 
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TABLE  TEN 

COVARIANCE  TABLE  FOR  MISSION  REQUIREMENTS 

(Demonstrating  the  Close  Relationship  between 
Operational  Characteristics  and  Interface) 


OPCHAR  variance 
INTERFACE  variance 
COVARIANCE 


-  *  -  *  .  ;  *  ■  -** 


.00138 

.00061 

,0008ii 


ments.  The  strength  of  the  covariance  outweighs  the 
Interface  variance  and  is  better  than  sixty  percentum  of 
Operational  Characteristics  variance.  The  recombining  of 
the  two  covariant  variables  into  a  single  Operational/ 
Interface  Characteristics  variable  was  done  and  is  shown 
in  Appendix  Eleven.  Selected  statistics  lifted  from  that 
computer  run  are  shown  in  the  last  half  of  Table  Nine. 


It  was  suspected  that  the  computer  run  with  the 
combined  Operational/interface  Requirement  variable 
(Appendix  Eleven)  would  not  alter  significantly  the  high 

bivariate  relationship  between  Mission  Requirements  and 
Design  Requirements,  and  this  was  found  to  be  true.  Ta¬ 
ble  Eleven  shows  that  relationship.  The  covariance  be¬ 
tween  the  two  variables  is  seventeen  times  that  of  the 
Design  Requirements  variance.  Unlike  the  case  of  Inter¬ 
face  Requirements,  there  is  no  ready  answer  for  this 
observation. 

Two  streams  of  thought  must  be  explored  in 
searching  for  an  answer.  Either  there  is  something  in 
the  data  or  data  analysis  which  is  distorting  the  model, 
or  the  model  is  accurate  and  a  logical  underlying  rea¬ 
son  exists.  The  data  collecting  procedures  were  reviewed 
and  the  analysis  of  requirement  fits  to  classical  defin¬ 
itions  (Table  Seven)  was  considered.  The  greatest 
chance  for  error  in  classifying  requirements  is  in  the 
intermediate  categories  of  Operational  Characteristics 
and  Interface  Requirements  as  each  has  a  conceptual  over¬ 
lap  with  two  other  requirement  types.  One  of  those  over¬ 
laps  is  with  each  other,  which  has  been  shown  to  be  pro¬ 
nounced.  The  two  end  types,  Mission  Requirements  and 
Design  Requirements,  are  the  easiest  to  define.  The 


TABLE  ELEVEN 

COVARIANCE  TABLE  FOR  OPERATIONAL/INTERFACE  CHARACTERISTICS 

(Demonstrating  the  close  relationship  between 
Mission  Requirements  and  Design  Requirements) 


MISREQ  variance 
DERSS  variance 
covariance 


3-6709 

.0110 

-1739 
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likely  place  for  making  an  error  having  such  an  impact 
is  in  Mission  Requirements  because  of  its  small  numbers. 
This,  however,  is  the  easiest  category  of  all  to  isolate 
and  count.  The  data  counting  procedure  was  dropped  from 
further  consideration.  The  smallness  of  the  Mission 
Requirement  numbers  may  cause  the  category  to  suffer 
distortions  in  the  statistical  processing  used.  A  re¬ 
quirement  change  on  the  base  one  hundred  is  a  one  per- 
centum  change.  Done  on  the  base  ten,  however,  it  is  a. 
ten  percentum  change.  If  a  counting  error  occurea  in 
Mission  Requirements,  the  comparison  of  raw  numbers, 
while  being  distorted,  would  probably  not  be  fatal.  When 
this  same  data  is  transformed  tc  a  rate  of  growth,  the 
error  is  magnified.  Since  the  requirement  categories 
measured  exhibit  a  difference  in  numbers  approaching  one 
order  of  magnitude,  the  possibility  exists.  Mission 
Requirements,  both  conceptually  and  observed  in  most 
projects  exhibit  no  growth  from  the  initial  number.  A 
number  erroniously  chosen  at  first,  will  stay  with  the 
rest  of  the  counting.  The  potential  for  errors  which 
affect  growth  rates  lies  in  counting  the  increased  Mis¬ 
sion  Requirements  above  the  established  base  whether  it 
was  counted  properly  or  not.  If  there  is  an  error,  it 
is  likely  both  conceptually  and  procedurally  to  be  an 


unwarranted  increase  in  the  growth  rate.  Following 
this  logical  premise  leads  one  to  question  just  how  far 
away  from  zero  growth  the  Mission  Requirement  observa¬ 
tions  were  and  if  that  difference  was  significant.  The 
difference  does  not  appear  large,  but  one  must  suspect 
the  sensitivity  of  a  small  sample.  This  sensitivity  an¬ 
alysis  can  be  done  by  assuming  the  conceptually  postu¬ 
lated  zero  growth  for  Mission  Requirements  and  running 
the  computer  program  with  this  input.  If  correlation  is 
still  high  between  the  two  requirement  types  in  this  an¬ 
alysis  one  must  seek  the  answer  somewhere  else  than  with 
Mission  Requirement  counting  of  analysis  techniques. 

When  this  is  done  (see  Appendix  Twelve)  one  sees  that 
the  R  square  drops  from  .86721  to  .79696  reflecting  that 
the  vast  majority  of  correlation  cannot  be  related  to 
Mission  Requirement  errors.  It  would  seem  logical  at 
this  point  that  some  underlying  conceptual  reason  should 
be  sought. 

Three  Most  Significant  Findings 

The  three  most  significant  findings  concerning 
requirements  are  s 

1)  the  taxonomy  received  support  as  an  indicator 
of  central  tendencies,  but  there  is  a  large 
number  of  poor  fits  in  each  category  except 
Mission  Requirements  5 
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2)  no  support  of  bivariate  relationships  between 
time  and  requirements  is  seen,  and 

3)  an  unexplained  correlation  between  Mission 
Requirements  and  Design  Requirements  makes, 
what  originally  looked  like  good  multivari¬ 
ate  regressions,  questionable. 

The  finding  that  a  theoretical  taxonomy  of  re¬ 
quirement  types  is  evident  in  existing  specifications  is 
a  positive  inducement  to  continue  refining  the  counting 
process.  Partitioning  of  the  total  set  of  requirements 
into  logical  groups  is  the  first  step  in  understanding 
and  controlling  requirement  growth.  Basically  put,  com¬ 
mon  requirement  types  and  patterns  lead  to  common  solu¬ 
tions  . 

The  finding  that  bivariate  relationships  are  not 
strong  over  time  is  significant  to  the  assumption  of  or¬ 
derly  growth.  Mission  Requirements  were  expected  to  be 
time  independent  but  the  other  types  were  expected  to 
have,  at  least,  fair  correlations  with  time  and  increas¬ 
ing  slopes  as  they  progressed  through  requirement  types 
towards  Design  Requirements.  Both  the  correlations  and 
slope  coefficients  of  Operational  Characteristics  and 
Interface  Requirements,  while  hovering  in  the  .30  range, 
are  not  quite  in  the  range  expected.  The  Design  Require¬ 
ment  slope  coefficient  and  correlation  are  clearly  not 
as  predicted,  being  on  the  same  order  as  Mission  Re- 


quirements.  Some  other  conclusion  than  direct  and 
strong  relationships  of  the  Mission  Requirements  causal 
theory  must  be  considered  unless  the  apparent  inconsis¬ 
tency  can  be  cleared. 

The  unexplained  correlation  between  Mission  Re¬ 
quirements  and  Design  Requirements  is  significant  be¬ 
cause  it  indicates  a  direction  to  search  in  seeking  an 
explanation  to  the  apparent  inconsistancy . 


CHAPTER  SEVEN  -  -  IMPLICATIONS  OF  THE  RESEARCH 

The  assumption  of  orderly  growth  had  been  estab¬ 
lished  from  long  standing  observation.  These  observa¬ 
tions  included  the  recognition  that  when  a  project  start 
to  take  shape  in  the  conceptual  stage,  the  type  of  re¬ 
quirement  is  almost  always  Mission  Requirements  with  sen 
gross  Operational  Characteristics.  It  is  known  that  a 
project  near  completion  exhibits  a  clear  majority  of 
Design  Requirements  with  a  lesser  number  of  Operational 
Characteristics.  These  observations  led  to  the  logical 
premise  that  more  detailed  requirements  grow  from  less 
detailed  ones  in  a  decision  tree  type  of  pattern. 

The  correlation  of  Design  Requirements  with  Mis¬ 
sion  Requirements  and  the  lack  of  correlation  of  either 
of  these  to  Operational  Characteristics  makes  this  pro¬ 
posed  pattern  unlikely  without  some  modifications. 

Possible  Alternate  Explanations 

As  the  computer  nun  with  Mission  Requirement 
growth  set  to  zero  showed,  the  apparent  correlation  be¬ 
tween  Design  Requirements  and  Mission  Requirements  is 
not  caused  by  Mission  Requirements  acting  unpre diet ably . 
A  profile  of  little  or  no  growth  is  assumed  and  the  data 
supports  it.  Design  Requirements  are  postulated  to 
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have  the  greatest  growth,  but  its  pattern  is  actually 
indicative  of  the  Mission  Requirement  low  growth  pro¬ 
file. 

One  good  reason  for  low  Design  Requirement 
growth  might  well  reside  in  the  use  of  specifications. 
Specifications  are  primarily  descriptive  documents  which 
show  the  status  of  a  project's  development  at  some  point 
in  time.  Specifications  are  also  referenced  documents 
which  show  the  status  of  a  project's  development  at  some 
point  in  time.  Specifications  are  also  referenced  doc¬ 
uments  on  research  and  development  contracts.  As  such, 
new  or  changed  specification  requirements  carry  the  po¬ 
tential  for  a  change  in  the  agreed  effort  to  be  accom¬ 
plished  by  the  contractor.  This  effort  is  defined  in 
the  contract  statement-of-work  which  is  written  in  gen¬ 
eral  terms  to  allow  some  flexibility  for  design  in  con¬ 
ditions  of  uncertainty.  Changes  in  the  statement-of- 
work  normally  carry  with  them  cost  and  schedule  in¬ 
creases.  These  are  anathema  to  a  well  run  project.  The 
specification  analog  to  loose  statement-of-work  state¬ 
ments  is  the  use  of  Operational  Characteristics.  It  is 
possible  that  cautious  managers  substitute  Operational 
Characteristics  for  Design  Requirements  in  their  evol¬ 
ving  specifications  as  often  as  feasible.  Operational 


Requirements  can  usually  be  met  by  a  variety  of  Design 
Requirements;  Design  Requirements  are  highly  constrain¬ 
ing.  Since  the  Design  Requirement  is  normally  expected 
to  be  the  last  category  of  requirement  completed,  a 
strategy  of  filling  in  the  spaces  in  an  evolving  speci¬ 
fication  with  relatively  flexible  Operational  Character¬ 
istics  and  cf  holding  off  Detail  Requirements  as  long  as 
possible  can  be  used  and  still  give  the  appearance  of  a 
well  run  and  orderly  development. 

Interface  Requirements  were  originally  evaluated 
because  it  was  believed  that  an  increased  level  of  de¬ 
tail,  as  a  Fart  One  specification  evolves,  would  force 
resolution  in  key  areas  by  Interface  Requirements.  In¬ 
terface  Requirements  put  Operational  Characteristic  con¬ 
straints  on  one  side  of  an  interface.  The  increase  of 
Design  Requirements  makes  one  half  of  many  interfaces 
firm.  This  is  properly  balanced  by  an  increase  in  Op¬ 
erational  Constraints  on  the  yet  to  be  resolved  side  of 
the  interface.  Although  Design  Requirements  did  not 
grow  as  anticipated,  neither  did  Interface  Requirements 
which  conforms  to  the  understanding  of  the  relative  re¬ 
lationship. 

The  problem  of  interface  is  thus  also  apparently 
controlled  at  the  part  One  level  by  staying  with  Opera¬ 
tional  Characteristics  as  long  as  possible.  Acceptance 


of  this  explanation  of  the  early  substitution  of  Opera¬ 
tional  Characteristics  for  Design  Requirements  and  Inter¬ 
face  Requirements  as  the  fastest  growing  category  is 
inconsistant  with  the  originally  conceived  pattern  of 
growth  for  each  of  the  categories  but  does  not  rule  out 
some  type  of  order  in  the  growth . 

When  one  works  with  linear  regressions  in  a 
specified  range  of  inquiry,  the  natural  tendency  is  tc 
consider  extending  the  regression  outside  the  range. 

There  is  one  assumption  of  growth  which  will  make  the 
observed  results  generally  fit  the  conceptual  model  but 
it  requires  extrapolation  of  Design  Requirements  in  a 
curvilinear  pattern.  Exhibit  Three  shows  this  construc¬ 
tion.  Design  growth  may  be  retarded  in  Part  One  speci¬ 
fications  because  of  reasons  previously  given.  At  the 
beginning  of  the  Part  Two  specification,  Design  Require¬ 
ments  would  take  off,  making  the  combined  Part  One  and 
Two  pattern  reflect  an  exponential  curve.  The  Part  One 
pattern  might  be  so  flat  that  small  samples  would  paral¬ 
lel  the  results  of  a  linear  relationship.  Examining  the 
relevant  range  of  Exhibit  Three,  one  could  therefore 
suppose  a  high  correlation  between  the  apparent  straight 
lines  of  Mission  Requirements  and  Design  Requirements. 

The  observed  correlation  is  .86721.  One  would  suppose 
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tnat  since  these  two  categories  don’t  grow  much,  their 
correlations  with  time  would  be  small.  The  actual  cor¬ 
relations  with  time  are  .01438  and  .14226.  One  would 
expect  the  very  least  correlation  with  time  to  be  for 
Mission  Requirements.  This  is  true.  Once  Design  Re¬ 
quirements  are  assumed  to  grow  exponentially,  one  would 
expect  Operational  Characteristics  to  show  the  greatest 
growth  in  the  relevant  range.  The  actual  correlation  is 
the  best  at  .34225.  Lastly,  one  would  expect  all  of 
these  relatively  flat  lines  to  relate  well  with  one  an¬ 
other  which  is  reflected  by  the  high  multivariate  rela¬ 
tionships  . 

The  model  in  Exhibit  Three  proposes  a  slightly 
altered  but  conceptually  valid  demonstration  of  orderly 
growth.  It  accounts  for  the  apparent  conflict  between 
theory  and  observation  of  Design  Requirements  growth  by 
showing  how  a  low  measured  growth  and  high  perceived  con 
ceptual  pattern  can  be  reconciled  in  the  relevant  range 
of  observation.  It  is  recognized  that  the  leap  from  re¬ 
search  findings  to  this  possible  alternate  explanation 
is  a  leap  forward  from  the  data  analysis  but  the  concep¬ 
tual  jump  is  small  and  supported  by  observations  of  the 
interrelated  patterns  among  the  requirement  types. 


CHAPTER  EIGHT 


SUMMARY 


In  military  projects,  goals  are  represented  by 
technical  requirements  in  development  contracts.  Process 
is  represented  by  various  other  contractual  requirements 
and  by  the  management  systems  in  force.  A  review  of  pub¬ 
lic  administration  history  has  shown  that,  through  a 
process  described  as  functional  rationalism,  the  bulk  cf 
America's  public  agencies  have  lost  their  perspective 
on  goals  because  of  their  preoccupation  on  the  processes 
used  in  gaining  those  goals.  Air  Force  projects  consti¬ 
tute  a  special  form  of  public  agency  and  they  evidence 
manifestations  of  this  common  problem. 

Specifically,  Air  Force  history  has  shown  a  pro¬ 
clivity  to  rationalize  development  of  a  project  into 
formal  phases  in  a  life  cycle,  and  to  further  manage 
each  of  these  phases  according  to  a  series  of  manuals 
and  management  systems.  As  in  the  generalized  case  for 
public  administrations,  the  harm  done  is  not  seen  to  be 
inherently  incorporated  in  the  particular  systems,  man¬ 
uals  and  life  cycle  phases  but  rather  in  the  resultant 
lack  of  attention  on  requirements. 

Direct  academic  research  on  technical  require¬ 
ments  has  been  scarce.  Early  studies  were  marked  by 
emphasis  of  the  uncertainty  and  complexity  inherent  in 
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technical  projects.  The  main  thrust  of  such  studies  was 
that  the  marked  uncertainty  and  complexity  of  weapon  sys¬ 
tem  acquisitions  clearly  differentiate  those  efforts  from 
developments  in  the  private  sector. 

Some  writers  classified  the  more  important  re¬ 
quirements  as  "technical  performance  parameters"  and 
proposed  systems  for  their  control.  Others  traced  the 
specific  effects  on  programs  of  uncertainty  and  complex¬ 
ity  to  external  and  internal  sources  and  emphasized  con¬ 
trolling  these  factors. 

Martin,  in  his  1971  dissertation,  used  an  entropy 
analog  to  analyze  the  amount  of  information  (and  accord¬ 
ingly  decision  alternatives)  in  a  project  development. 

He  related  this  entropy  (defined  as  a  measure  of  the  in¬ 
formation  in  a  system)  directly  with  the  increasing  a- 
mount  of  information  in  a  project  development  and  argued 
that  more  information  inherently  meant  more  choices 
hence  more  uncertainty .  This  led  to  his  adaptation  of 
the  second  thermodynamic  law  which  says  that  the  tendency 
exists  for  a  system's  entropy  to  always  increase. 

Martin's  use  of  an  increasing  information  base 
appears  to  be  an  abstract  counterpart  to  the  evolving 
technical  requirement  baseline  and  thus  his  dissertation 
is  one  of  the  few  efforts  which  addresses  requirement 
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growth  directly.  Its  focus,  however,  is  a  "grand  scheme 
explanation  of  how  uncertainty  operates  on  a  highly  gen¬ 
eralized  information  (or  requirement)  growth  network. 
This  doesn't  allow  isolation  of  specific  types  of  re¬ 
quirement  growth . 

Following  Martin's  lead,  an  analogy  to  learning 
theory  was  investigated.  The  investigation  did  not  pro¬ 
vide  a  readily  usuable  framework,  as  it  did  in  Martin's 
case,  but  it  served  to  sharpen  the  perspective  on  what 
should  be  studied.  Learning  theory  contains  two  basic, 
and  not  completely  compatible  theories  on  learning.  The 
Wundtian  Elemental  school  forwards  the  proposition  that 
items  are  learned  and  remembered  independently  of  assoc¬ 
iations  with  other  ideas.  The  rote  memory  work  of  mul¬ 
tiplication  tables,  spelling  tests  and  the  like  attest 
to  the  widespread  application  of  such  a  learning  theory. 
The  Gestalt  school,  however,  believes  that  learning  and 
memory  depend  on  interaction  of  the  items  in  question 
with  other  already  learned  items.  One  must  satisfy  him¬ 
self  as  to  the  logical  relationship  in  order  to  remember 
Perhaps  the  best  current  example  is  the  association 
methods  taught  in  memory  classes  for  remembering  names 
and  places. 

In  weapon  system  acquisition,  heavy  emphasis 
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has  been  placed  on  the  role  of  complexity  in  making  such 
developments  difficult.  This  complexity  has  been  shewn 
to  grow,  in  part,  as  the  unanticipated  result  of  com¬ 
bining  two  requirements  which  are  themselves  simple. 

Thus  a  synergy  effect  occurs  where  the  resultant  com¬ 
plex  problem  is  greater  than  the  sum  of  the  individual 
problems.  This  characteristic  is  analogous  to  a  Gestalt 
process  where  the  whole  of  a  problem  is  more  than  the 
summation  of  its  parts,  but  rather  a  summation  of  parts 
plus  associations.  Following  the  lesson  of  this  Ge¬ 
stalt  analogy  to  its  logical  conclusion,  one  is  led  xo 
realize  that  technical  requirements  cannot  be  understood 
in  isolated  categories. 

The  terms  "military  project"  and  "weapon  system 
acquisition"  have  previously  been  used  interchangeably 
and  without  further  definition.  This  was  done  primarily 
to  gather  under  one  roof  all  of  the  diverse  writings  and 
research  in  the  field  which  run  a  gambit  from  big  pro¬ 
grams  to  small  projects  and  from  Navy  to  Army  to  Air 
Force. 

The  conceptual  model  uses  the  aggregate  comments 
based  on  definitions  using  any  one  or  a  combination  of 
these  terms  to  explore  the  historical  development  and 
background.  The  comments  give  a  direction  to  search  in 
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making  the  conceptual  model,  but  if  one  is  to  go  further, 
a  more  precise  definition  is  necessary.  The  conceptual 
model  uses  the  technically  oriented  project  offices  of 
the  United  States  Air  Force.  Each  such  project  office 
controls  the  development  of  a  product  by  one  or  more 
technical  contractors  using  development  contracts. 

These  contracts  include  a  set  of  requirements,  described 
by  Strayer  and  Lockwood  ass 

1)  Mission  Requirements  -  -  basic  statements  of 
product  mission, 

2)  Operating  Characteristics  -  -  basic  functional 
statements, 

3)  Design  Requirements  -  -  details  on  design  and 
specification  compliance, 

4)  Interface  Requirements  -  -  added  to  the  Strayer/ 
Lockwood  list  as  functional  statements  that  con¬ 
strain  the  interface  between  two  requirements, 

5)  Management  System  Specifications  -  -  basic  man¬ 
agement  systems, 

6)  Legal  Obligations  -  -  Walsh-Healy  Act,  etc.,  and 

7)  Programming  Requirements  -  -  schedule  and  fund¬ 
ing  arrangements . 

Each  product  controlled  by  a  project  office  is  technic 
cally  defined  by  the  first  four  requirement  types.  Con¬ 
trol  is  exercised  over  a  product's  development  life 
cycle  which  includes  conceptual,  validation,  full-scale 
development,  production  and  deployment  phases. 
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The  conceptual  model  proposes  that  the  various 
technical  requirements  are  present  in  commonly  used  de¬ 
velopment  specifications  and  that  requirements  can  be  is¬ 
olated  and  counted  such  that  an  aggregate  number  in  each 
category  can  be  totaled.  Further,  the  model  proposes 
that  there  is  a  discemable  bivariate  trend  of  growth 
for  each  requirement  type  over  time  and  therefore  neces¬ 
sary  multivariate  relationships  as  well.  The  specific 
patterns  of  growth  are  postulated  to  be  linear  or  a 
transform  function.  Specifically,  Mission  Requirements 
are  seen  to  remain  relatively  steady  over  time.  Opera- 
tional  Characteristics  are  seen  to  exhibit  some  growth, 
Interface  Requirements  more,  and  Design  Requirements  the 
most . 

The  case  is  centered  on  the  validation  phase  of 
a  project's  life  cycle.  The  document  selected  is  the 
part  one  Critical  Item  Specification.  The  research  site 
is  selected  as  Wright-Patterson  Air  Force  Base  in  Dayton, 
Ohio.  Projects  were  selected  in  avionics  because  of  re¬ 
searcher  familiarity  with  the  subject.  The  number  of 
projects  evaluated  was  established  at  seven. 

Since  the  thrust  of  the  research  is  on  the  com¬ 
mon  aspects  of  requirement  growth,  the  identification  of 
requirements  by  project  was  relaxed  to  allow  all  require- 
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merits  of  a  particular  type  to  be  summed  together.  This 
increased  the  sample  size  by  allowing  time  to  be  the  one 
common  denominator  among  samples. 

Research  finding?  were  not  total  support  of  either 
the  process  of  requirement  counting  or  the  conceptual  mod¬ 
el  on  interrelations.  Requirement  types  seen  in  Fart  Cr.e 
specifications  are  scrtable  by  category,  but  the  overlap 
between  types  is  large  and  discourages  precise  use  of  the 
results.  The  bivariate  relationships  of  the  requirement 
types  with  time  are  not  fully  in  line  with  the  conceptual 
model  in  the  relevant  research  range.  This  range,  it 
should  be  remembered,  is  the  period  of  development  of  the 
Fart  One  Critical  Item  Specification  in  the  acquisition 
phase  of  a  product's  life  cycle.  During  this  period, 
Mission  Requirements  and  Design  Requirements  seem  to  have 
highly  common  growth  patterns.  The  two  are  highly  cor¬ 
related  with  each  other.  The  two  have  commonly  low  cor¬ 
relations  with  time.  They  have  similiar  slope  coeffi¬ 
cients.  The  circumstance  of  common  slope  coefficients  is 
important  because  it  strikes  directly  at  the  heart  of  the 
differential  growth  hypothesis.  Design  Requirements  were 
thought  to  have  the  most  different  not  the  most  common 
slope  with  Mission  Requirements.  It  is  statistically 
inappropriate  to  depend  on  a  comparison  of  common  slope 
coefficients  where  correlations  are  so  low.  The  conclu- 


sion  of  common  slopes,  as  seen  in  the  computer  results, 
was  accordingly  supported  using  a  different  approach. 

Design  Requirements  show  a  high  bivariate  rela¬ 
tionship  with  Mission  Requirements.  This  means  that 
sufficient  linearity  exists  between  the  two  that  one  can 
predict  the  other  with  high  certainty  using  a  direct 
mathematical  relationship.  Going  a  step  further,  if  one 
can  accurately  be  measured  against  time,  so  can  the  other. 
This  establishes  common  tendencies  of  linearity  with  time 
for  the  two  variables,  but  it  does  not  establish  the 
occurance  of  common  slope  coefficients.  Further,  the 
common  tendency  with  time,  sc  far,  has  been  seen  to  be  one 
of  low  correlation.  Addressing  this  low  correlation  with 
time,  the  Mission  Requirement  correlation  was  seen  to  be 
low  because  the  data  points  parallel  the  X  axis,  n.  t  be¬ 
cause  of  a  wide  spread  of  data  points.  In  essence,  the 
data  support  a  strong  linear  relationship  and  a  well 
defined  slope  for  Mission  Requirements  which  is  truly  not 
correlated  with  time  in  that  no  matter  how  much  time 
elapses,  Mission  Requirements  are  not  seen  to  grow.  The 
high  correlation  between  MISREQ  and  DERSS  accordingly 
takes  a  greater  significance.  Further,  evaluation  of  the 
Design  Requirement  data  points  confirms  that  they  also 
follow  the  low  scatter,  low  slope  profile  of  Mission 


Requirements .  This  analysis  supports  the  computer 
findings  of  relatively  common  and  low  slopes  for  Mission 
Requirements  and  Design  Requirements.  As  again  evidenced 
in  the  high  multicollinearity  between  Mission  Requirement 
and  Design  Requirements  in  the  multivariate  relationships 
Design  Requirements  are  inappropriately  related.  Ey  usir. 
the  explanation  of  an  exponential  or  other  sharply  rising 
change  in  Design  Requirements  during  the  Part  Two  spec¬ 
ification  development,  the  study  results  can  be  recon¬ 
ciled  to  a  conceptually  sound  growth  theory. 

This  points  up  both  the  limits  and  the  value  cf 
this  dissertation's  results.  The  research  concludes  that 
requirements  can  be  counted  and  that  the  simplest  model 
of  differential  linear  growth  of  requirements  in  Part  One 
specifications  is  not  valid  as  postulated.  In  keeping 
with  the  dictum  of  Occam's  Razor-  the  simplest  set  of 
assumptions  needed  to  explain  a  phenomenon  is  best-  a 
single  change  is  proposed  as  a  target  for  future  study. 
Such  a  future  study  should  start  with  a  validation  of  the 
requirement  counting  process.  Appendix  Three  gives  a  * 
proposal  for  doing  this. 


CHAPTER  NINE 


RECOMMENDATIONS  FOR  FUTURE  STUDY 


A  major  purpose  of  this  dissertation  is  to  pro¬ 
vide  a  way  for  counting,  and  possibly  sampling  require¬ 
ments.  Hopes  for  sampling  have  been  dimmed  by  the  re- 
se  rch  results  because  of  the  apparently  large  overlap 
between  requirement  types.  It  is  possible  that  more  car. 
be  done  to  crystalize  the  categories  such  that  the  over¬ 
laps  will  diminish.  To  this  end,  Appendix  Three  is  writ¬ 
ten  to  offer  suggestions  as  to  how  a  study  of  this  type 
might  proceed. 

In  the  area  of  requirement  relationships,  the 
obvious  first  step  is  to  check  part  two  specifications  to 
see  if  Design  Requirements  take  off  in  an  upward  dir¬ 
ection  as  suggested  by  this  research.  Other  alternatives 
also  follow  obvious  forms.  Expansion  of  the  study  across 
a  wider  base  of  avionics  is  the  first  step.  This  serves 
as  a  validity  check  on  the  results  already  accomplished. 
After  that,  extension  to  other  functional  areas  can  be 
considered.  As  sophistication  in  the  counting  and  an¬ 
alyzing  process  increases,  the  research  can  be  extended 
to  large  programs  where  specifications  have  a  lot  of 
interaction  among  themselves. 

No  evaluation  of  the  requirements  growth  process 
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would  be  complete  without  more  than  passing  attention 
paid  to  deliberately  constraining  growth.  Interviews 
with  numberous  project  leaders  and  staff  elicited  a  com¬ 
mon  belief  that  those  requirements  developed  early  in 
acquisition  should  be  held  firm.  One  author-*-  emphasizes 
the  early  involvement  of  contractors  in  writing  system 
specifications  as  one  way  to  insure  that  changes  are 
minimized . 

Other  authors2  continue  a  written  track  of  the 
project  managers'  consensus  on  control  of  growth.  They 
list  several  "errors"  of  management.  Setting  require¬ 
ments  without  user  involvement  is  the  first  type  of  er¬ 
ror.  Their  subsequent  list  of  errors  generally  involves 
changing  those  requirements  without  user  involvement. 

Lack  of  involvement  of  the  using  military  commands  (Tac¬ 
tical  Air  Command,  Strategic  Air  Command,  etc.)  is  a  rel¬ 
atively  recent  criticism.  In  fact,  the  counter  complaint 
that  user  involvement  led  to  unnecessary  changes  led  to 
an  emphasis  on  reduced  command  influence  as  a  cornerstone 
of  the  McNamara  era.  Acceptance  of  user  inputs  does  not 
necessarily  mean  unnecessary  requirements,  however.  The 
wisdom  of  what  original  requirements  to  hold  fast  in  the 
face  of  a  rapidly  changing  environment  must  take  account 
of  the  experience  of  those  forced  to  live  (or  die)  with 
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results.  This  research  can  serve  to  make  the  distinction 
of  requirement  types  more  clear  and  emphasize  the  large 
scale  implications  of  changing  Mission  and  high  scale  Op¬ 
erational  Requirements. 
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CHAPTER  NINE  ENDNOTES 


1.  See  Dietrich's  article  "System  Acquisition  -  How 

A-109  Can  Help  Shorten  the  Process"  in  Government 
Executive,  Volume  9  (Bibliography  number  10) .  ~ 

2.  Reference  Ferratt  and  Starke's  article  "Avoiding 
System  Mismanagement"  in  Journal  of  Systems  Manage¬ 
ment,  Volume  29  (Bibliography  number  1^). 
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APPENDIX  ONE 


BACKGROUND  RESEARCH  SOURCES 

The  subject  of  technical  requirements  growth  came 
as  a  spin-off  to  an  original  interest  in  control  of  en¬ 
gineering  changes.  As  a  technically  complex  weapon  sys¬ 
tem  is  developed,  changes  to  the  design  are  inevitable. 
These  engineering  changes  are  damaging  to  a  program  not 
only  because  they  are  inherently  costly,  but  also  because 
they  often  stretch  a  development  schedule  which  allows 
the  dual  problems  of  idle  engineering  capacity  and  in¬ 
flation  to  operate . 

One  must  know  precisely  the  base  of  requirements 
at  any  two  points  in  time  in  order  to  properly  evaluate 
the  engineering  changes  occurring  between  those  points. 
The  addition  of  a  new  requirement  is  not  a  legitimate 
change.  Further,  it  is  probable  that  the  differences  in 
absolute  numbers  of  requirements  between  programs  inher¬ 
ently  leads  to  differences  in  engineering  changes.  Lar¬ 
ger  programs  likely  have  more  changes.  These  two  con¬ 
clusions  make  it  necessary  to  accurately  measure  require¬ 
ments  in  order  to  understand  engineering  changes. 

It  became  immediately  apparent  that  even  a 
sketchy  understanding  of  requirement  isolation  and 
counting  did  not  exist.  Tracking  this  problem  led  to 
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researchers  concerned  with  the  problem  and  to  their  or¬ 
ganization,  the  Air  Force  Business  Research  Management 
Center  located  at  Wright-Patterson  Air  Force  Base  in 
Dayton,  Ohio.  This  center  was  established  to  coordinate 
and  evaluate  research  in  business  oriented  procurement 
methods.  The  researchers  in  the  center  specialize  in 
different  functional  areas  and  broker  research  in  their 
specialty  to  different  Air  Force  students  and  agencies. 
When  an  avenue  of  research  is  particularly  promising, 
funding  for  private  research  is  considered.  Technical 
requirement  growth  is  the  concern  of  both  the  center's 
chief,  lieutenant  Colonel  Daniel  Strayer  and  of  Captain 
Lyle  Lockwood.  These  two  have  a  good  balance  of  aca¬ 
demic  background  and  practical  experience.  Their  paper 
on  the  subject  called  "What  Are  We  Buying  Here?"  is  the 
basic  foundation  of  the  dissertation  because  of  its  pro¬ 
posed  taxonomy.  Beyond  this  vital  research  done  by 
Strayer  and  Lockwood,  another  resource  offeree  by  the 
center  was  the  collateral  studies,  many  of  which  are 
documented  in  the  center's  Semiannual  Business  Research 
Reports .  Using  this  document  and  reports  suggested  by 
the  center  staff,  the  serious  work  of  tracing  the  back¬ 
ground  of  technical  requirement  growth  research  was  be¬ 
gun.  The  process  started  here  is  standard  in  academic 
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research  and  involves  tracing  the  bibliographies  of  rel¬ 
evant  documents  to  other  pertinent  documents  and  con¬ 
tinuing  the  process  until  good  sources  are  exhausted. 


This  line  of  research  using  the  center's  re¬ 
sources  led  to  the  nucleus  of  research  reports  and 
studies  for  the  dissertation. 

Two  other  major  resource  centers  are  located  at 
Wright-Patterson  Air  Force  Base.  The  first  is  the  li¬ 
brary  of  the  Graduate  School  of  Logistics.  This  library' 
is  important  to  the  dissertation  because  it  is  an  Air 
Force  access  point  to  the  Defense  Logistics  Studies  In¬ 
formation  Exchange.  Using  the  Exchange’s  descriptor 
list,  a  bibliography  was  established  and  reports  ordered. 

The  second  center  is  the  Air  Force  Institute  of 
Technology's  Engineering  Library.  Dissertation  Abstracts 
International ,  while  not  an  exclusive  resource  of  this 
library  is  a  necessary  one  to  review  and  is  available 
there.  The  areas  of  Business  Administration  and  Systems 
Management  were  found  to  be  the  most  fruitful  and  were 
reviewed  for  similar  dissertation  topics  -  -  none  were 
found.  One  almost  has  to  live  in  the  environment  of 
technical  engineering  management  to  undertake  such  a 
topic  so  the  lack  of  close  subjects  was  not  surprising. 

Air  University  Abstracts  of  research  reports  was 
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reviewed  for  topics  using  the  categories  of  System  Man¬ 
agement,  Requirements,  Technical  Performance  Parameters, 
System  Program  Management,  and  Project  Management. 

Two  other  sources  in  the  library  are  the  Inter¬ 
national  Aerospace  Abstracts  and  the  Keyword  Index  of 
AFIT  Student  Resident  Theses .  These  sources  are  marked 
by  the  fact  that  the  respective  bibliographies  are  not 
computerized  so  that  they  must  be  entered  using  keywords 
and  do  not  allow  combinations. 

Other  sources  are  more  individually  tailored. 

The  University  of  Texas  of  Texas  at  Austin's  computer¬ 
ized  search  of  journals  and  periodicals  called  INFORM  was 
run.  The  Defense  Documentation  Center's  computerized 
bibliography  was  used  as  well  as  that  of  the  National 
Technical  Information  Service. 

The  general  library  facilities  of  The  University 
of  Texas  at  Austin  were  used.  NASA/SCAN  sheets  from  the 
National  Aeronautics  and  Space  Administration  were  re¬ 
viewed  and  the  81-01  series  of  Aerospace  Management  was 
found  to  be  the  best  source.  Papers  and  books  recom¬ 
mended  by  committee  members  were  used. 
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REQUIREMENT  CLASSIFYING  AND  COUNTING  PROCEDURES 

Assumptions  Made  in  Counting 

It  is  immediately  apparent  that  some  of  the  re¬ 
quirements  seen  in  a  part  one  specification  are  included 
more  than  once.  This  practice  is  generally  accepted  be¬ 
cause  of  the  dual  nature  of  specifications.  They  serve 
as  technical  guidance  and  description,  on  one  hand,  and 
a  contractual  standard  of  performance  on  the  other.  Re¬ 
quirements  are  often  specified  in  some  places  primarily 
to  add  context  to  other  requirements  but  must  be  repeated 
later,  in  the  appropriate  place,  to  assure  contractual 
coverage.  This  repetition  is  small  compared  to  the  total 
number  of  requirements  and  is  ignored  in  the  research. 

Many  standards  for  design  and  testing  are  codi¬ 
fied  in  various  Department  of  Defense  specifications  and 
standards  used  by  the  Air  Force.  Each  such  specification 
is  designed  for  common  application  across  projects,  and 
hence,  compliance  over  time  evokes  standard  responses  *to 
design,  test  procedures,  etc..  Each  such  standard  is  as¬ 
sumed  to  be  in  the  government  system  if  it  is  listed  in 
the  latest  Department  of  Defense  Index  of  Specifications . 
Each  such  specification  or  standard  is  treated  as  one  re¬ 
quirement  each  time  it  is  reference  in  a  specification. 
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Procedures 

What  defines  a  single  requirement?  This  problem 
is  easy  to  answer  in  concept  but  quite  difficult  in  prac¬ 
tice.  One  should  remember  that  the  complex  nature  of 
requirements  makes  statement  of  relationships  and  inter¬ 
faces  into  compound  statements,  sometimes  involving  many 
parts  in  order  to  properly  reflect  the  complex  nature  of 
the  relationship.  One  alternative  to  simplify  this  sit¬ 
uation  is  a  structural  content  approach.  This  leans  on 
the  idea  of  sentence  diagramming  rather  heavily.  It 
breaks  each  sentence  into  parts  and  analyzes  those  parts. 
The  following  sentence  is  presented  for  analysis: 

The  Omega  Air  Navigation  System  shall  operate  at 
the  low-frequency  wave  lengths  in  communicating 
navigation  information  between  aircraft  and  ground 
stations  over  long  distances. 

In  the  above  sentence,  "Omega"  is  simply  a  name,  yet  it 
is  now  a  government-required  label  for  the  system.  "Nav¬ 
igation"  is  a  requirement  as  to  function,  albeit  gross. 
"System"  requires  that  there  be  interrelated  components 
of  large  enough  size  to  warrant  being  called  a  system  in¬ 
stead  of  simply  a  unit,  "shall  operate"  is  a  requirement 
for  use  of  the  system  -  -  as  opposed  to  only  requiring 
a  system  mock-up.  "low-frequency  wave  lengths"  defines 
the  means  of  transmission  as  radio  (as  opposed  to  laser, 
for  instance)  and  it  further  constrains  that  operation  to 


140 


be  in  the  low  frequency  band.  "communicating",  when 
used  in  conjunction  with  "between",  requires  two  way 
transmission .  This  means  that  both  a  transmitter  and 
receiver  is  required.  Since  we  have  already  assumed  a 
receiving  capability  inherent  in  navigation  by  radio, 
this  has  added  a  transmitting  requirement,  "navigation 
information"  is  a  direct  output  of  already  required  nav¬ 
igation  system  operation,  hence  the  phrase  adds  nothing 
to  the  sentence  beyond  better  context,  "aircraft  and 
ground  stations"  denotes  a  specific  environment  in  which 
the  communication  will  occur,  "over  long  distance"  levies 
an  operational  requirement  which  will  ultimately  be  re¬ 
flected  in  transmitter  power  requirements  and  receiver 
sensitivity . 

When  one  analyzes  the  process  he  recognizes  that 
the  significance  of  each  phrase  was  very  critically  eval¬ 
uated.  One  can  quickly  grasp  the  magnitude  of  a  task 
which  requires  treatment  of  every  sentence  in  a  book¬ 
sized  document  in  like  manner.  Further,  the  absurdity  to 
which  one  is  reduced  is  much  like  a  psychiatrist  perform¬ 
ing  an  in-depth  analysis  of  a  person  based  on  how  he  said 
"Good  morning".  No  single  sentence  in  a  specification  is 
intended  to  stand  so  alone  that  interpretation  out  of 
context  will  always  be  clear.  This  alternative  reflects 
the  age  old  error  in  logic  -  -  mistaking  precision  for 
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correctness.  The  missing  ingredient  to  this  analysis  is 
context.  Once  the  context  in  which  the  sentence  was 
written  is  established,  the  sentence  can  again  be  eval¬ 
uated,  but  with  a  filter  to  screen  out  unwarranted  nu¬ 
ances  of  meaning.  Analysis  of  the  above  sentence  from 
the  context  of  its  being  an  introductory  statement  would 
lead  one  to  search  for  aspects  of  Mission  Rea_uirement  in 
the  statement.  Thus  the  system  is  seen  to  have  a  require¬ 
ment  for  long  range  air  navigation  using  ground  stations. 
While  this  approach  lacks  the  precision  of  the  previous 
approach  and  requires  experienced  judgement  to  apply  con¬ 
text  to  the  sentences,  it  is  the  best  reflection  of  what 
the  specification  writer  intended. 

Use  of  the  Procedure 

A  necessary  first  step  in  implementing  the  proced¬ 
ure  is  evaluation  of  the  specification  table  of  contents 
which  outlines  the  hierarchy  of  the  subject  covered.  Some 
specifications  have  a  more  detailed  outline  than  others, 
and  these  are  usually  less  likely  to  have  amalgamated 
paragraphs  of  diverse  subjects  than  the  less  structures 
specifications.  Close  evaluation  of  the  specification 
hierarchy  gives  necessary  insight  into  subject  context, 
so  vital  in  counting  requirements  in  any  given  sentence. 
Once  the  hierarchy  is  known,  a  brief  survey  of  the  con- 
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tents  should  follow  to  gauge  the  number  of  graphs,  ta¬ 
bles,  blank  paragraphs  and  other  features  likely  to  make 
the  specification  atypical. 

Classifying  and  counting  requirements  are  two  con¬ 
ceptually  different  functions  which  tend  to  merge  when 
one  becomes  familiar  with  the  process.  Each  sentence  can 
be  broken  down  into  a  number  of  candidate  requirement 
statements  without  regard  to  type.  This  process  leans 
heavily  on  the  context  of  the  statement  for  guidance. 

Once  candidates  are  separated,  the  valid  requirements  are 
typed.  Many  requirements  statements  are  not  complicated 
and  this  process  is  not  difficult  in  those  cases.  There 
are  many  complicating  factors,  however  and  these  must  be 
addressed. 

Paragraphs  which  consist  of  a  heading  only,  in 
order  to  reserve  a  space  in  the  specification  outline, 
are  not  counted  as  a  requirement. 

Sentences  and  paragraphs  marked  "to  be  deter¬ 
mined"  are  not  counted. 

Items  on  the  list  of  applicable  documents  found 
in  the  front  of  specifications  are  not  counted,  since 
they  must  be  specifically  referenced  in  the  body  of  the 
specification.  Their  appearance  here  is  only  for  refer¬ 
ence  . 

Each  reference  to  other  system  or  Critical  Item 
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Specifications  is  counted  as  one  requirement. 

Tables  which  array  data  in  a  matrix  form  shall 
have  each  cell  count  as  one  requirement. 

Functional  diagrams  showing  interfaces  between 
components  shall  reflect  each  arrow  which  denotes  inter¬ 
face  as  one  requirement.  Ancillary  notes  on  the  diagram 
are  counted  just  as  if  they  were  text. 

Graphs  with  points  plotted  on  a  two  dimensional 
scale  shall  have  each  point  count  as  a  requirement. 

Where  there  is  an  outside  boundary  or  performance  en¬ 
velope,  it  shall  count  as  one  additional  requirement. 

Revisions  to  specifications  are  made  periodically. 
These  revisions  are  not  always  reflected  as  totally  re¬ 
vised  documents  but  rather  as  revision  notices  attached 
to  the  original  document.  If  such  a  revision  notice  is 
used  to  establish  new  requirement  type  numbers,  care  must 
be  taken  to  insure  that  net  changes  in  number  are  sought 
rather  than  the  number  of  revisions.  Some  revisions 
change  an  already  existing  requirement  which  would  total 
one  revision  but  a  net  of  zero  new  requirements. 

Operational  Characteristics  are  generally  func¬ 
tional  statements,  while  Design  Requirements  relate  to 
attributes  possessed  by  an  item.  Although  the  distinc¬ 
tion  is  not  always  clear,  anything  expressed  in  terms  of 
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quantities  generally  measures  an  attribute  and  is  there¬ 
fore  a  Design  Requirement. 

Relationships  between  Design  Requirements  are 
never  Interface  Requirements. 

Wiring  diagrams  which  include  attributes  such 
as  voltage  are  Design  Requirements. 

Product  requirements  which  relate  to  test  con¬ 
ditions  or  environment  are  Design  Requirements. 
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APPENDIX  THREE 

A  PROPOSED  FUTURE  REQUIREMENT  COUNTING  STUDY 
Introduction 

If  evaluation  of  the  requirement  counting  pro¬ 
cedure  had  resulted  in  clear  and  objective  standards, 
then  replication  of  the  procedure  would  have  been  simple. 
The  dissertation  concludes,  however,  that  some  form  of 
bounded  subjectivity  is  the  best  one  can  ever  do  when 
counting  requirements.  A  crucial  question  thus  remains 
as  to  whether  the  subjective  decision  process  can  be  suf¬ 
ficiently  bounded  to  give  usuable  and  repeatable  results. 
The  crux  of  this  issue  is  not  whether  one  unique  person 
can  replicate  his  own  results,  but  rather  if  a  group  of 
qualified  researchers  can  do  it. 

This  appendix  describes  one  way  in  which  con¬ 
sensus  among  such  researchers  might  be  gained.  The  goal 
of  the  research  is  to  produce  replicable  results  in  a 
specification  requirements  counting  process.  Since  sub¬ 
jectivity  is  woven  into  fabric  of  the  problem,  more  than 
a  list  of  rules  is  anticipated  as  outcome.  First,  there 
must  be  such  a  list  to  bound  subjectivity  as  much  as  can 
be  done.  Secondly,  however,  insights  into  classes  of 
problems  encountered  is  necessary. 
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Study  Group  Constitution 

It  is  obvious  that  the  study  group  members  must 
be  already  familiar  with  the  military  research  and  devel¬ 
opment  processes  to  be  effective.  The  more  current  a 
member's  experience,  the  more  useful  it  will  be. 

The  investigation  must  be  rooted  in  good  analysis 
procedure.  The  disciplined  approach  required  for  such  a 
study  is  traditionally  required  of  graduate  students.  The 
group  is  envisioned  to  contain  three  students.  Although 
group  consensus  represents  the  optimum  support  for  a  re¬ 
sultant  group  finding,  it  is  recognized  that  this  does 
not  happen  for  every  point  and  thus  a  tie  breaking  number 
is  selected.  The  specific  operations  of  the  group  is  not 
a  necessary  subject  for  extensive  prior  definition  since 
the  group's  size  is  small  enough  to  allow  group  proced¬ 
ures  to  conform  to  differences  in  member  personalities. 
Agreement  on  the  time  frame,  support  functions  such  as 
typing,  and  conflict  resolution  procedures  should  be 
squared  away  as  soon  as  possible. 

Group  Dynamics  -  -  The  Learning  Process 

Reading  and  discussing  this  dissertation  and  the 
included  requirements  taxonomy  is  the  first  step.  This 
is  primarily  an  individual  effort  with  the  supervising 
professor  acting  as  coordinator.  Use  of  the  dissertation 
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gives  every  member  a  common  base  of  departure  in  evalu¬ 
ating  the  taxonomy.  Each  member  should  independently 
write  his  questions  and  criticisms  of  the  material  and 
submit  them  to  the  supervising  professor.  Independently 
derived  inputs  might  well  overlap  but  it  gives  the  best 
chance  for  a  wide  perspective.  While  consensus  opinions 
derived  from  group  processes  are  sought  at  the  end  of  the 
research,  they  should  be  discouraged  early.  The  super¬ 
vising  professor  will  sort  the  comments  and  questions  and 
put  together  an  aggregate  agenda  for  the  first  group 
discussion.  The  first  discussion  group  is  aimed  at  the 
non-specific  goal  of  merely  understanding  the  requirement 
categories  and  how  they  relate.  This  might  require  more 
than  one  meeting,  but  the  group  should  resist  going  on 
without  completing  it.  One  member  should  act  as  secretary 
and  document  unresolved  issues  and  agreements  alike. 

When  the  group  thinks  it  understands  the  separate  re¬ 
quirement  types,  it  should  propose  an  initial  process  for 
counting  them. 

Group  Dynamics  -  -  The  Synthesis 

Classically,  thesis  and  antithesis  meet  and  re¬ 
sult  in  a  synthesis.  In  this  case,  the  study  group  has 
developed  its  own  thesis  from  a  critique  of  the  disserta¬ 
tion.  Antithesis  is  embodied  in  the  confrontation  of  an 
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actual  specification  with  the  thesis.  The  synthesis 
should  be  a  more  usuable  requirements  counting  procedure 
and  possibly  some  enlightened  comments  on  the  process. 

The  actual  specification  given  should  be  carefully  se¬ 
lected.  It  should  reflect  the  common  characteristics  of 
current  specifications.  It  is  not  prudent  to  start  eval¬ 
uation  with  the  most  atypical  specification  but  rather 
the  study  should  build  slowly  from  the  most  common  base 
to  various  types  of  atypical  specification  (too  many 
graphs,  lack  of  clear  product  hierarchy,  etc.).  The 
first  evaluation  of  these  specifications  should  again  be 
individual  effort.  In  effect,  this  makes  three  embryonic 
first  syntheses  instead  of  one.  The  first  point  of  com¬ 
parison  would  then  be  between  each  study  member's  raw 
total  counts  in  each  category.  This  is  appropriate  be¬ 
cause  the  ultimate  test  of  repeatability  lies  in  the  raw 
number  counts. 

This  process  will  lead  to  new  procedures  and  in¬ 
sights  which  should  be  separately  recorded.  One  should 
resist  trying  to  tie  insights  from  each  iteration  togeth¬ 
er  until  later  in  the  study  in  order  to  leave  large  lat¬ 
itude  for  developing  threads  of  thought  without  imposing 
preconceived  patterns  on  the  data.  The  process  should 
proceed  through  first  synthesis  to  two  more  iterations 
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using  different  parts  of  the  target  specification  in 
each  case. 

Study  Results 

At  this  point,  the  threads  of  insight  about 
classes  of  problems  and  exceptions  to  procedures  should 
be  traced  and  major  conclusions  made.  A  final  test  of 
the  procedures  should  be  made  by  evaluating,  once  again, 
the  original  specification  section  which  had  been  eval¬ 
uated  only  that  once.  Enough  time  should  have  trans¬ 
pired  by  now  to  have  negated  any  originally  patterned 
thoughts.  Analysis  of  the  variances  from  the  original 
data  counts  for  each  requirement  category  can  be  ac¬ 
complished.  The  greatest  change  in  numbers  should  re¬ 
flect  the  greatest  conceptual  shift.  This  avenue  should 
be  explored  and  compared  to  the  major  insights  derived 
independently.  Convergence  of  one  or  more  student's 
final  count  on  another's  original  count  might  reflect 
the  presence  of  a  strong  personality  rather  than  a  log¬ 
ical  shift.  The  primary  test  will  be  to  see  if  the 
spread  of  raw  data  counts  in  each  original  requirement 
category  was  reduced  significantly  in  the  final  count 
between  the  researchers  and  if  the  reduced  spread  is 
explained  by  the  changed  procedures  and  insights.  This 
last  requirement  is  vital,  since  any  group  of  people 
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working  together  over  a  period  of  time  on  one  subject 
will  probably  see  their  thoughts  converge.  Only  those 
convergences  that  can  be  expressed  in  revised  procedures 
and  clear  insights  can  validly  be  considered  as  affec¬ 
ting  the  general  ability  of  the  requirement  counting 
process  to  be  replicated. 
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APPENDIX  FOUR 
PROJECT  SOURCE  DATA 


Project  A 

Project  A  is  a  low  frequency  navigation  system 
labeled  the  AN/ARN  131  Omega  System.  The  specification 
used  is  model  specification  33657-74-R-0673  dated  10  May 
1974.  It  was  revised  on  30  July  1975* 

Project  B 

Project  B  is  a  digital  inertial  measurement  unit 
designated  the  AN/ARN  101(V).  Its  specification  is  CB 
101-033-35351  dated  3  October  1975  and  revised  on  1  De¬ 
cember  1976. 

Project  C 

Project  C  is  a  two  way  radio  operating  in  the 
225  to  399*975  Megahertz  frequency  range  and  it  is  desig¬ 
nated  the  ARC  164(V).  The  specification  is  ENCA  Exhibit 
72-9  dated  28  November  1972  and  revised  4  March  1974. 

Project  D 

Project  D  is  an  interface  electronics  unit  de¬ 
signed  to  interface  with  the  LN-15  inertial  measurement 
unit.  Its  specification  is  EC  229-10082-1  dated  22  De¬ 
cember  1972  and  revised  12  September  1974,  8  August,  1975 
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and  4  March  1977. 


Project  E 


Project  E  is  a  terrain  following  radar  unit  data 
terminal.  Its  specification  is  EC  229-10059-1  dated  29 
April  1979  and  revised  24  September  1979,  8  August  1975* 
29  September  1976  and  7  March  1977- 


Project  F 

Project  F  is  a  defensive  system  electronics 
counter-measures  receiver.  Its  specification  is  00752- 
EC07878  139-0601  dated  5  June  1975  and  revised  16  Sep¬ 
tember  1975»  7  November  19?5»  26  September  1976  and  1 
March  1977. 


Project  G 

Project  G  is  an  electronically  steerable  antenna 
system.  Its  original  specification  was  ENADD  Exhibit 
76-21  dated  11  May  1977  and  subsequently  revised  and 
superseded  by  specification  1708006  dated  5  December  1977 
and  itself  revised  on  2  January  1978. 
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